Many railway organisations depend on ageing systems that are difficult to replace. They are expensive to maintain, difficult to secure and increasingly hard to integrate with modern technology. Modernising them is not simply a technical challenge. Changes must be introduced without disrupting critical operations. The real challenge isn’t deciding whether to modernise gradually, but how to manage each stage: how much to move at once, what to monitor afterwards and when to pause or roll back.
Your rollback strategy determines your pace
Most teams see rollback as a last resort, something they hope they’ll never need. In reality, it should shape the migration strategy from the start. If rollback takes minutes, a larger migration step may be acceptable. If it takes several hours, each step must remain small enough for the operational impact to stay manageable.
That’s why rollback time matters before planning begins, not after. Measure how long it actually takes to return each type of system to its previous state and let that define the migration schedule. It also tends to produce a useful question: are the systems with the slowest rollback the same ones you were planning to move in a single step?
A rollback you haven’t tested isn’t a rollback
A rollback plan isn’t proven on paper. It’s proven when someone has executed it under realistic conditions and knows exactly how long it takes. That’s often when the hidden issues emerge:
- Data created in the new environment that also needs to be rolled back
- Systems that were redirected to the new platform and now need to be switched back.
- Critical knowledge that sits with someone who isn’t on call when things go wrong
None of these are exceptional. They simply stay hidden until the rollback is put to the test.
Decide what to monitor before you move
A migration stage that completes without errors isn’t necessarily a successful one. The signals that matter often appear later, but only if you’ve decided in advance what to look for. Focus on three things:
- First, how the system performs under real operational load rather than test conditions, because quiet periods reveal very little.
- Second, what users report in the first days after the migration. They usually notice friction long before monitoring tools do.
- Third, how much manual intervention the new environment still requires. If it needs constant attention to stay healthy, you’ve moved the workload, but you haven’t finished the migration.
Agree the stopping conditions in advance
The hardest moment in any migration isn’t when something clearly goes wrong. It’s when the signals are concerning but inconclusive, while the pressure to keep moving keeps growing. Timelines, momentum and visible progress all push in the same direction.
That’s why your stopping conditions should be agreed before the migration starts. Not an exhaustive list of thresholds, but a clear set of questions: What would make us pause? What would make us roll back? And who has the authority to make that decision? None of this makes a migration faster, but it does make it easier to control. And in railway environments, where operations can’t simply stop, that’s often far more valuable than speed.
Atos helps railway organisations modernise complex environments through phased migration, continuous monitoring and tested rollback strategies, while keeping critical services running.
