Why Unmaintained Dynamics Projects Become Expensive Later

There is a widespread state in Dynamics systems: the system runs and the service provider is gone. It often runs surprisingly long and surprisingly stable. That is exactly why the state looks harmless. The costs of missing maintenance arise all the same, just not as an invoice. They arise as a provision that falls due at some point. Here are four items, from the perspective of the person who pays for them in the end.

Item one: the restart

At some point the first bigger change comes: a new module, a legal requirement (for example e-invoicing), a connection through an interface, the migration of classic workflows to Power Automate, and so on. The new service provider starts with a discovery phase. Its duration depends directly on the state. With a documented system, it takes days. Otherwise it can easily take weeks. Those weeks show up on the future invoice, because every vendor prices in the uncertainty it finds.

Item two: technology with an expiry date

Microsoft keeps developing the platform and announces the end of old features. This happens years in advance, but it still has to be watched. A maintained system moves along in small steps. An unmaintained one collects the deprecations until one of them goes live. Then all the rebuilds have to happen at once. In the worst case, as a project under deadline pressure. Spread out, the same rebuild would have cost a few days per quarter. Bundled and rushed, it costs many times more.

Item three: the knowledge that leaves

The people who knew the system move on. Without maintained documentation, every departure takes knowledge with it for good. Later, someone fills the gap at a daily rate through reverse engineering. This is the only one of the four items that can never be made up for. Documentation that was not created during the build will never be as cheap again as it was then.

Item four: the options that shrink

The quietest item. An unmaintained system makes future decisions more expensive. The migration costs more because nobody knows the stock. Changing vendors becomes riskier, which weakens your negotiating position toward the existing one. Even shutting down becomes costly, because it is unclear what all hangs on the system. So you pay for missing maintenance even if you want to get rid of the system one day.

What follows

The countermeasure is unspectacular, and that is exactly why it is realistic: a fixed, small maintenance rhythm. Twice a year, survey the state, compare the deprecations, work through the most urgent findings and update the documentation. That is a fraction of a project budget and keeps all four items small.

The decision about it is not made in IT, though. It is made by those who, hopefully, have read this text up to here. Missing maintenance is not a saving but a loan with bad terms. And as with every loan: the sooner you pay it off, the less it has cost.