Dynamics 365 – Buried Skeletons

Recently, our contact on a large multi-year customization effort for a customer left. The new person who came in seemed to be of a mind to change things up. What was a highly effective and collaborative effort, suddenly became a battle over every hour billed. I’m on the verge of kicking them to the curb, but…

Screwed by Nature

There is an interesting anomaly in our business, that can ultimately lead to disaster; the seeds are planted as soon as you hire a Microsoft Partner. I don’t think customers think about the end at the beginning. Why would they? They have no idea just how bound to that partner they will become over time.

Houses of Cards

You will ultimately be working with a person who is architecting your solution to meet your described requirements. Assuming they know what they are doing, they still have multiple ways to go about it. “Best Practices” is a bullshit term, don’t get lured by it. While there are many ways to architect something wrong, there are also many ways to architect it right. It will boil down to that person’s opinions based on their knowledge and past experiences. But even the most knowledgeable and experienced people will architect things differently from each other. They are all right!

It’s not intentional. Eventually, all complex deployments become houses of cards. It’s just how it is. Removing any card. without knowing what it may be holding up, can crash everything down. This is why most partners being brought in to replace another, suggest starting many things over from scratch. It would just take too much time in forensics to figure out what the prior partner had done and why, (“What does this card do?“). This is regardless of whether it was done well or poorly. I’m sure some partner will jump on the comments and say they are smart enough to figure out anything. These are the ones that usually come back later and say “Upon further review, the last partner did not know what they were doing, and we need to start over“… convenient.

Transition to Internal Team

The big customization effort is complete! Let’s have our own people take over from here. This is a natural and logical desire. But you better plan on keeping your partner around, and happy, because there will be issues and fires. There always are. They tend to pop up before you can even get clear of your partner. The bigger the deployment, the more dependent you are on the partner who built it, they are only ones who know where the skeletons are buried. The only bigger risk is having one of your employees build it.


There is a lot of conversation today about “Citizen Developers”. They will also build houses of cards, but will likely do it poorly, without the deep knowledge and experience, and then suddenly they leave your company. Admittedly, when we are called into these scenarios, starting over is often the only option.


All platforms go through continuous updates, Microsoft Business Applications included. These can not only bring new features, but occasionally can deprecate features you are using. As a customer with your own business concerns, you will likely not be up-to-speed on these, and will instead discover them one day when things stop working. That would be a fire, and you better have a brigade at the ready. Better yet, if you have maintained a good relationship with your partner, they will give you a heads up, and be there to make sure things continue to go smoothly.


This is not a Microsoft Business Applications phenomena, this is the same for all platforms that allow for broad customization. The same was true when we were Salesforce.com partners. It’s also not new. The same was true for that Access Database solution Joe built for you ten years ago, and then he was hit by a bus and died. Damn Joe!


Eventually your partner will have you by your underwear band. Whether they give you a wedgie will have a lot to do with who they are, and how your have engaged with them. The cost of changing them will be very high, and last a very long time. Choose wisely.

Steve Mordue MVP


9 Responses

  1. Bryan Tuttle says:

    Thank you for writting this up! Exactly my experience as a fellow partner and consultant. I would add customers that say skip the doc to spare the dollar should have a paragraph or two here as well. Or the client that nickels and dimes the project because they think development or customization is the same as “configuration”. And can’t comprehend the complexity or art it takes in structuring a scalable solution.

    Clearly I could go on. Great post!

  2. Hosk says:

    It would be better if the simple options were chosen and tried before the complex solution was implemented bit at the start of the project when time, Monday and effort seen unlimited then irrational decisions are made

  3. Monty says:

    I agree that you need to keep your partner sweet (like in real life), but surely your aim should be to be self sufficient over time? At some point your in house team should be taking over tasks that you have been paying your partner to do. Especially if you have an in house IT team. Get them trained.

  4. Josh Booker (@joshuaabooker) says:

    What about the Access solution built 20 years ago and still runs fine? Folks with Access skills are a dime a dozen – chances are a few were riding the bus that hit Joe. So we’re good.

    • Steve Mordue MVP says:

      Not sure than someone using an Access Database today is what I would call “good”, maybe “good enough”, probably ignorant to options

      • Josh Booker (@joshuaabooker) says:

        Wish it were not so but name one other rapid development option having both: forms over data and reporting. Now name one with zero licensing cost.

        • Steve Mordue MVP says:

          Seems like a loaded question from a RapidStartCRM user :). But, responding as though you were not, I would say that there is significant additional value for that cost, assuming they utilize it.

          • Josh Booker (@joshuaabooker) says:

            Not judging your solution, just pointing out there is no MSFT solution since Access enabing both rapid development and paginated reporting since Access. Export to Excel is not reporting and SSRS\RDL in xRM\CDS is like a hidden capability that noone uses (as such I fear it may just stop working someday).

