Three items missing from your TCO calculation

Most calculations for a digital solution have two lines. The build, with a figure taken from the quote. And maintenance, with a figure that is often a percentage of the build.

The second line is the problem. Behind the word maintenance sit three costs that arise for different reasons, behave differently over time, and can be budgeted separately. Merge them into one lump sum and the budget will break, and rarely where you expected.

One: the work other people order on your behalf

A customer portal or reseller portal is connected to several systems, and each of them has its own release schedule. You control the pace of none of them.

Look at Litium's own release notes for the last twelve months, September 2025 to August 2026, counting the platform without add-ons. Twelve feature releases, one a month. Sixteen patch releases in between, so anyone following the current version line has twenty-eight versions to take a view on. Fifteen of the changes are marked as breaking. More than forty fixes are marked as critical. Two security fixes arrived without warning, and one of them was released to fifteen version lines at once.

Now add the ERP. Business Central arrives in two major release waves a year, in April and October, with cumulative updates most months in between. Microsoft also publishes which code is going away. Anything marked as obsolete disappears after three release cycles, around eighteen months, and whatever was built on top of it may then stop working. The date is known in advance, but it is set by someone else.

Then there is shipping, payments and search, each with versions of its own. Payments bring regulatory requirements on top, and those arrive when they arrive.

The total comes to more than forty occasions a year when something around the solution changes. Most require no action at your end, but somebody has to read them and decide that. Making that judgement takes time even when the answer is no.

This is the most predictable of the three items, because every calendar is public. It is also the one most often missing from the calculation altogether.

Two: the knock-on defects from your own changes

Every change you make to the solution carries a risk that something else stops working. That is not an accusation against whoever builds it. It has been measured.

In a study of four large operating systems, including Linux and FreeBSD as well as a commercial system with twelve years of history, between 15 and 24 percent of post-release fixes turned out to be incorrect in ways that affected users. One fix in five, in other words, created new work. The study also points to why: 27 percent of the incorrect fixes were made by developers who had never worked in the files they were changing.

Budget for it. Make twenty changes in a year and some of them will come back. That is not a sign of a poor supplier. It is a sign that the solution is in use and that somebody is touching it.

This item grows with how much you change yourself, which also makes it the one you can steer. Build little and it stays small.

Three: the rebuilds

Nobody wants to budget for the third item, because it feels like an admission of failure. It is not.

Lehman's laws of software evolution were formulated in the seventies and still hold. A system in use has to change, or it gradually becomes less useful. And as it changes its complexity grows, unless somebody actively works to keep it down. Quality declines if nobody maintains the structure and adapts it to the world around it.

In practice that means parts of the solution occasionally need to be rebuilt rather than patched once more. An integration built against one version of the ERP and then adjusted seven times is no longer the same integration. At some point rebuilding it becomes cheaper than continuing to repair it.

A rebuild of a defined part of the solution every three or four years is normal. Leave it out of the budget and it will still happen, only as an unpleasant surprise in the middle of a financial year.

What does not belong here

New development. New functions, new flows, another portal, another market.

That is an investment in the business and belongs on a line of its own, with its own justification and its own return. Mix it in with the three items above and two things happen, both bad. The maintenance budget looks inflated and gets questioned. And when the money runs out anyway, it is development that gets cut, which is precisely what you bought the solution for.

Keep them apart. One line for keeping the solution working and compatible. One line for what you want to achieve.

Ask your supplier which of the three are included

It is a simple question, and the answer tells you a lot. Is compatibility work at upgrades included, or quoted every time? Who pays when a fix needs fixing? Is there any plan at all for rebuilds, or is it patched until something breaks?

We have put the first two into a fixed monthly cost through Glanser Care, and we take responsibility for keeping the solution working as the platform and the integrations are upgraded. The third we plan together with you in advance, so that it lands in a budget rather than in an emergency. New development we keep separate, for the reasons above.

If you want to see how the three items look for your current solution, we will carry out an assessment. You point us to your domain and set aside two hours for a meeting. Within 72 hours of that meeting you get an inventory of functionality and integrations, a functional specification going forward, a prototype and a complete cost picture with a timeline. The assessment is free, and the material is yours whatever you choose to do next.

Sources

Number of releases, breaking changes and critical fixes: Litium's public release notes for the platform, September 2025 to August 2026, counted without add-ons and accelerators.

Business Central release waves and the handling of obsolete code: Microsoft Learn, Dynamics 365 Business Central.

Share of incorrect fixes: Yin, Yuan, Zhou, Pasupathy and Bairavasundaram, "How Do Fixes Become Bugs?", ESEC/FSE 2011.

On systems having to change and complexity growing as they do: Lehman's laws of software evolution.