Modernising a business platform while maintaining continuity
How DNA Solutions modernised an established business platform in stages, comparing each change with the existing behaviour before it went live, while operations continued.
ITBusiness continuity
01The situation
An established business platform supported a company’s core operations. As requirements grew, every change took longer to deliver, because responsibilities inside the platform depended closely on one another.
Replacing the platform in one step would have put all the risk on a single date, with little room to verify the result beforehand. Operations also had to continue throughout the change.
Replacing everything at once
- All the risk on one date
- Hard to verify beforehand
- Difficult to reverse
Changing in stages
- Risk split into small steps
- Each step compared before the switch
- Each step can be reversed
02What had to be protected
- Operations continue throughout the modernisation.
- Business records stay consistent from one stage to the next.
- Every change is compared with the existing behaviour before users depend on it.
- Each responsibility ends up in a component that can change on its own.
- Business rules become easier to find and to adapt.
03How each stage works
The platform was modernised one responsibility at a time. Each stage followed the same cycle, and a stage closed only when the compared results matched.
- Choose a responsibility
Each stage starts with one responsibility of the platform, chosen for its value and for how cleanly it can be separated.
- Build the component
The responsibility is rebuilt as its own component, with a defined interface to the rest of the platform.
- Run both
For a period, the established platform and the new component process the same work. The results of the established platform remain the reference.
- Compare the results
Results from both are compared. Every difference is explained and resolved before the stage can close.
- Switch
When the results match, the new component takes over that responsibility.
- Then
- Start the next stage
The next stage starts from a platform that works and carries one responsibility fewer.
04How the platform changed over the stages
Each stage moved one responsibility out of the established platform. The platform became smaller with every stage, and the business kept working until the modernisation was complete.
05Design decisions
Small, reversible stages
Each stage carries a limited amount of change, so a problem is easier to locate and to reverse.
Comparison before every switch
Confidence comes from comparing results on live work, before users depend on the new component.
Clear boundaries
Each business rule lives in an identifiable component. Changing a rule no longer requires understanding the whole platform.
06How we run a staged modernisation
Plan the order of the stages
Agree the sequence with the teams responsible for operations, so that each switch fits their calendar.
- Stage plan
Set the switching criteria
Write down, before each stage, which results must match and who decides the switch.
- Switching criteria
Share the comparisons
Share the comparison results at every stage, so that decisions rest on evidence.
- Comparison reports
Document each component
Record, for each new component, its responsibility, its interface and its rules, so that the teams in charge can run and change it.
- Component documentation
07Results
Change concentrated in one risky step
Change delivered in small, verified stages
Responsibilities tangled inside one platform
Components that evolve independently
Business rules hard to find and change
Rules easier to locate and adapt
Risk of interrupting operations
Operations continued throughout
08When this approach fits
A good fit when
- The platform supports operations that cannot stop.
- The platform must keep evolving during the change.
- Behaviour must be proven before users rely on the new version.
- The platform can be divided into distinct responsibilities.
Probably not needed when
- A small application with few users: a direct replacement may be simpler.
- A platform being retired without a successor.
Questions to ask before a similar project
What we clarify with a company before modernising a platform that cannot stop.
Why not rewrite the platform in one go?
A single replacement puts all the risk on one date and leaves little room to verify the result before users depend on it. Stages keep each change small enough to compare, verify and reverse.
How do you prove that a new component behaves correctly?
For a period, the established platform and the new component handle the same work. Their results are compared, and every difference is explained before the switch.
Which responsibility should move first?
Usually one with clear value and clear boundaries, so that the first stage proves the method with limited risk. The order of later stages follows from what the first ones teach.
Why is this case study anonymised?
We do not publish client names, sectors, systems, volumes or dates for work of this kind. Details about a company’s systems can help attackers, so they stay out of anything public. We describe the method and the result instead.