Legacy System Migration Strategy
How Telos approaches the transition from a legacy system to a new application — covering parallel running, data migration, cutover, and the principle of keeping V1 live until V2 is ready. Use when a customer has an existing system that needs to be replaced rather than extended.
Legacy System Migration Strategy
Replacing a live system is different from building something new. There is an existing user base, existing data, and a business that cannot stop while the new system is built. Telos handles this through a structured migration approach that minimises risk and keeps the business running throughout.
The core principle: V1 stays live until V2 is ready
The customer gets zero value from the new system until it is switched on. That means the goal of the BUILD phase is a single, clearly defined event: cutover — the moment V1 is switched off and V2 is switched on. Everything in the build phase is oriented toward reaching that point.
Until cutover, V1 continues to operate. Telos recommends keeping the existing developer (if there is one) maintaining V1 during the BUILD phase. This keeps the current system stable and removes pressure from the new build to be "done" before it's truly ready.
Parallel running
During BUILD mode, both systems run side by side:
- V1 handles live operations
- V2 is being built, tested, and validated
This allows the customer to test V2 thoroughly against real data and real workflows without disrupting the business. It also provides a safety net — if something is wrong with V2, V1 is still there.
Discovering hidden features
Legacy systems accumulate features over time, many of which are undocumented or forgotten. Telos can analyse the existing codebase to surface functionality that the customer may not have thought to mention. This reduces the risk of building V2, going live, and then discovering something important was missed.
This does not mean rebuilding everything that exists in V1. The migration is an opportunity to be deliberate: identify what is actually used and valued, and leave behind what is not.
Data migration
Data migration is executed as a two-stage process:
- Test migration — A full migration of production data into the new system, used to identify issues, gaps, and edge cases. The customer tests against this data.
- Cutover migration — Once the test migration is clean and the system is validated, a final migration is performed at the point of go-live.
This approach means the cutover itself is low-risk — it is a repeat of a process that has already been tested and refined.
What drives the timeline
The cutover point is the milestone that shapes the entire BUILD phase. If the goal is six months to cutover, then the BUILD price is structured around that six months — not around the size of the software. The scope of what gets built is adjusted to fit the timeline, not the other way around.
This means the right question is not "how long will it take to build everything?" but "what do we need to build to reach a point where V2 can go live?"