How to Modernize Legacy Software Without a Rewrite

It varies with scope, but incremental modernization is designed to deliver improvements within weeks per slice rather than making you wait for a single large release. A focused effort on one or two modules often shows results in a quarter, while modernizing an entire platform is a multi-quarter roadmap delivered in stages. The advantage is that value arrives continuously, so you are never far from the last useful outcome.

Yes, and you usually should. The strangler-fig approach is built to run alongside normal development, because new features can be added to the modern components while the legacy parts keep operating. The key is coordination: sequence the work so feature teams and modernization work touch shared areas deliberately rather than by accident.

That is common and manageable. Treat the running system's behavior as the specification, and capture it with characterization tests and observation before making changes. This turns undocumented behavior into a verified baseline, which also reduces the risk of regressions during migration.

Often, but not automatically. Rehosting to the cloud can cut infrastructure and maintenance overhead and unlock managed services, yet lifting a poorly structured application unchanged can carry its problems along with it. Decide based on cost, scalability needs, and compliance, and pair the move with at least some replatforming so you gain real benefit.

Yes, when the underlying technology is unsupportable, the data model can no longer serve the business, or maintenance risk outweighs the cost of rebuilding. Even then, favor replacing components incrementally rather than a big-bang rewrite, so you avoid a long period with no delivered value. The decision should come from evidence gathered in discovery, not frustration with the current system.