I’m going to gloss over a critically important decision here at the beginning, but I promise we’ll get back to it. In fact, this decision is the point of this post, and the biggest determiner of legacy replacement project success. But we’ll get to that.

‍

Incremental

One way to replace a legacy system is to draw a line around a part of the system, replace just that part, then put the replacement part into production while deleting the original part.

‍

‍

Incremental replacement requires some awkward patching while you have the old & new systems running at the same time.

• You have to find a way to get data back and forth.
• You have to operate and monitor the old and new systems and their interaction.

‍

In return for the inconvenience, you get visibility into the progress of replacement. No more “we spent all the money and nothing is ready for production”. You also get options for priority. Some parts of the old system are more urgently in need of replacement than others. Replace those first. You get reversibility. If the project goes haywire, the remaining parts of the old system are still there.

‍

All-At-Once (aka “Big Bang”)

The other way of replacing a legacy system is to replace it all at once. Why mess around with half measures? Just get it done and be done with it.

‍

You can’t just rub a lamp and have the new system appear. You’ll approach equivalence a little at a time.

‍

‍

The All-At-Once style has some notable gotchas:

• I blithely said “⅓” and “⅔”, but how do you measure? The last 20% of the system notoriously takes 80% of the effort, even if you plan for the last 20% of the system to take 80% of the effort.
• Context is always wider and more subtle than you are aware of at first. End-to-end is further than you think.
• People are part of the system. They only come along at the pace of people, not at the pace of programming.
• That last step, where you turn on the new system & turn off the old, is, to use the vernacular, a bitch.

‍

All of these gotchas compound, so the bigger the project the greater the chance of massive over-run or outright failure.

‍

False Dichotomy

Here’s the thing, though. Every replacement project is both incremental and all-at-once. Let me explain.

‍

Remember that decision we glossed over right up front? The key lies in the innocuous phrase “...draw a line around a part of the system…”. Everything outside of that line sees this project as an incremental change. At the same time you are replacing everything inside the line, an all-at-once project. You can’t go into production until the new part sufficiently mimics that part it’s replacing.

‍

‍

Now we can highlight the critical questions:

• How big an area goes inside the line? Powerful incentives push for bigger areas, but the bigger the area, the more the compounding gotchas get you.
• Which part of the system goes inside the line next? Are there changes to the boundaries that would make the next step easier? Harder?
• How much work should you do to prepare the old system to be replaced? It seems a shame to tidy things up in the old system since you’re just going to delete it in a day/week/month/year. At the same time, working with clumsy interfaces slows the whole project.

‍

Conclusion

At Mechanical Orchard our bias is towards smaller steps. We are, after all, replacing systems that for decades have been the beating hearts of large, successful businesses. Our engineering skills; our proprietary AI-based tooling, our organization structure; our marketing, sales, contracts; all ensure that we can effectively put smaller steps into production efficiently. With smaller steps comes greater transparency, more options for our clients, and opportunities to rapidly build trust.

‍