Most legacy application modernization projects fail on two simple options: a full feature freeze, or shipping new work on both systems for as long as the rebuild takes. The rule that usually works is a short, dated freeze on the area being rebuilt. Agree in writing that new features go only on the new system once each part of it is live.
If you are a CTO, you know this meeting. Sales has deals waiting on a feature. The old system gets more fragile with every release. Someone senior asks why the team can't just do both. This piece covers what each option costs in team time, risk and business pressure. It also shows how to get the business to agree the rule before anyone writes new code.
What are the three options, in plain terms?
There are three options, and each one moves the pain somewhere different. Pick based on where your organisation can take that pain.
- Full feature freeze. Nothing new ships on the old system until the new one replaces it. The team stays focused and the business waits.
- Dual build. New features ship on the old system and are also built, or later ported, on the new one. The business keeps moving and the team pays for every feature twice.
- New features only on the new system. The old system gets bug fixes, security patches and legal changes, nothing else. Any new capability is built on the new system, which goes live module by module next to the old one.
Why does a full feature freeze feel safe but rarely hold?
A freeze is easy to explain and engineers like it. It breaks because rebuilds almost always take longer than planned, and the business stops waiting long before the rebuild is finished.
The delay usually comes from inside the old system. Ten years of code hides business rules nobody wrote down: a discount that only applies to one region, or a report finance relies on every month-end. Each one you find adds weeks.
Then comes the first exception: one urgent feature for one important customer. Then a second one. Now you are running a dual build that nobody planned or budgeted for.
The early warning sign is simple. If someone asks for an exception in the first few weeks, your freeze will not last, so change the plan now.
What does a dual-build period cost your team?
A dual build lets the business keep shipping, but every feature needs two specs, two builds and two rounds of testing. The visible cost is time. The hidden cost is that the two systems slowly drift apart.
Drift is quiet. The old system rounds tax one way and the new one rounds it another way. A validation rule gets updated in one place and not the other. These gaps stay hidden until cutover, when real customer data runs through the new system and the numbers don't match.
There is a people cost too. The engineers who know the old system best get pulled back to maintain it, so the rebuild is left with the people who understand the business least. That is the opposite of what you need.
Is "new features only on the new system" the best default?
For most mid-size systems, yes, if the new system can go live in slices. It forces you to ship real parts of the rebuild early, and it keeps engineers from building the same feature twice.
It works best with the strangler approach. You put a routing layer in front of the old application and move one module at a time, such as billing, then scheduling, then reporting. Each module is switched over to the new system and its old code path is turned off.
The cost is that the business may wait for a feature until its area has moved. You can reduce that wait by migrating the areas with the most demand first, even when they are not the easiest technically. The real engineering work is the overlap: shared login, shared data, and keeping records in sync while both systems run. Plan for that from the start.
What does it cost to get this decision wrong?
The worst result is a rebuild that never finishes, where you run two systems indefinitely with a team split between them. You keep paying for both systems and never get the benefits of the new one.
You also lose trust. A freeze that breaks after two months makes leadership doubt every date you give them afterwards. Data mismatches at cutover can mean wrong invoices, missing records or a rollback in front of customers. Good engineers get tired of building the same thing twice and leave.
None of this comes from bad code. It comes from a rule that was never agreed, or was agreed vaguely.
Who can skip all of this?
Some teams don't need a formal rule. If the old system is small enough to rebuild in a few weeks, or the product is in maintenance mode with almost no feature requests, just freeze it and move on.
The same goes if your project is a hosting move rather than a rewrite. Moving an application to new infrastructure without changing its behaviour rarely needs a feature policy. A cutover plan and a rollback plan are usually enough.
How do you agree the rule with the business before the rebuild starts?
Put the rule on paper and get it signed by the people who will push hardest against it. Usually that means the CEO, the head of product and the head of sales. Do this before work starts, not when the first exception request arrives.
A sequence that works:
- List the roadmap for the next two quarters, with a named business owner for each item.
- Sort each item into one of three groups: must ship on the old system (legal, contractual or tied to a fixed date), can wait, or can be built on the new system first.
- Write the exception process. Name who can approve a change to the old system, what evidence they need, and how many weeks of rebuild delay the requester agrees to accept. Making that trade-off visible stops most casual requests.
- Put dates on everything. The freeze needs an end date and a review checkpoint, not "until it's done".
- Define "done" for each slice as the old code path being switched off, not "the new version works".
Use these decision rules to choose:
| If your situation is... | Then choose... |
|---|---|
| Short rebuild, light roadmap | Full freeze with a fixed end date |
| System splits into clear modules | New features only on the new system, busiest areas first |
| Contractual commitments on the old system, hard to split | Short dual build with a hard cap, porting each feature in the same sprint |
What should you ask your team or vendor before committing?
These questions show quickly whether a plan will survive contact with the business. Vague answers usually mean the rule hasn't been thought through.
- Which module goes first, and was it chosen for business demand or because it is technically easy?
- How will data stay consistent while both systems are live, and who checks it?
- Who is responsible for finding the undocumented business rules in the old code?
- What exactly happens when sales asks for an exception?
- On what date is each old code path turned off?
At Geminate Solutions, after 50+ products shipped, we have learned that the agreement matters as much as the architecture.
For the full picture on approaches and sequencing, read our guide to legacy system modernization. If you want another pair of eyes on your plan, ask Geminate Solutions for a free review. We reply within 24 hours.
Top comments (0)