In a medical device platform, modernization is a regulatory strategy

Modernization in a medical device platform is not just a technical strategy. Every module you replace is a change control event under IEC 62304.

The incremental migration, in four phases

1. Map boundaries. Map software item boundaries and safety classifications in the legacy system.
2. Build the facade. A routing layer between old and new. It is a software item, not infrastructure.
3. Replace incrementally. Each replacement is a change control event: new V&V, updated RMF.
4. Retire legacy. All traffic shifted, and the DHF updated to reflect the final architecture.

What changes versus a standard migration

• Every module swap is a change control event. A new item, a new classification, new V&V, and the DHF updated before deployment.
• The facade layer is a software item. It needs classification, V&V evidence and a place in the Software Architecture Description.
• The RMF evolves with every phase. New modules mean new SOUP and new failure modes. The RMF is a living document, not a submission snapshot.
• Monoliths make this expensive. No clean boundaries means impact analysis across the entire system on every change. The Strangler Fig works cleanly when software items are isolated, and becomes a DHF nightmare when you are extracting boundaries from a system never designed to have them.

Intentional modernization is a prerequisite, not a parallel activity. The boundaries you define before you start are the boundaries you manage in your DHF for the life of the product.