Could you have made major changes to subsystems in the original system and then gradually worked towards a total rewrite incrementally?

You would have had to work very carefully and have an extremely solid test framework and methodology but I'm wondering if it might not have allowed for adding the features the client wanted and prevented a situation where you had to do a major cutover on code that wasn't tested in the field.

What about responding to their feature requests... in the new system? !

Then they'd have the motivation to make the switch.

We tried that and that's how we eventually got them to switch - 2 years later. The client required a feature to start 'live sessions' with mobile subscribers whenever they were active on the network (made or received a call) and support for multi-level menus. The original architecture was transactional and they understood its limitations. The rewrite used SEDA and we were having latency issues, gc and memory issues handling live sessions with SEDA. So we had to do another upgrade to switch from SEDA to Actor based model that worked. The next upgrade was small and incremental compared to the first one very and we had the system ready by the time contract was finalized.

That's the problem. From my reading of the article, their client was, probably legitimately, concerned with the risk of a cutover to a new and unproven system.

To implement a new system the client always needs to do UAT. That's actually a drain on their resources, and if they have a working system it is far better to have incremental changes made and a regular set if bug fixes than to launch a new system, then find a raft of new bugs or unexpected changes that need to be fixed anyway.

Existing systems allow enterprises to operate effectively. New systems almost always cause unexpected disruption to a business regardless of efficiencies gained from the new system. And most IT systems are to support the objectives if the business, they aren't the actual objective if the business. A software development company can lose sight of this because it IS the objective of their business :-)

Good point. The UAT was definitely one of the reasons. It was several Excel spreadsheets long and scheduling it was a pain :-)

Also, it was a hosted service and client saw no value to them- just the pain. There was risk of service outage during the upgrade that would have had resulted in the loss of revenue. Also, the client had to provision extra resources to run Cassandra/SOA servers. In short, it was a lot of work for them with no benefit to them.