Define the change
Describe the business capability that needs to change and the constraint in the current system. Agree the behavior that must be preserved, the changes that are acceptable and who can approve the result. Use these requirements to compare migration, partial redesign and full redesign.
Map the dependencies
Follow business transactions through applications, interfaces, identity services, data stores and background jobs. Include reporting and administration. Identify who owns each dependency and what happens if it is unavailable. Review the relationships between hardware, infrastructure and software, including the operating assumptions of the proposed design. My technical background includes both software and hardware.
Choose the extent of redesign
A partial redesign needs clear boundaries between retained and replaced components, including interfaces and shared data responsibilities. A full redesign needs a plan for preserving required behavior. Compare microservices and monolithic designs against the organization’s ability to develop, deploy and support them. Document the reasons for the chosen approach.
Plan data movement and continuity
Agree data mappings, validation, reconciliation and exception handling. Decide how ongoing transactions are treated during migration. Prepare the cutover sequence, decision authority and conditions for pausing or reversing it. Account for changes already made to data and external systems. Examine the recovery plan and the eventual retirement of legacy components using evidence from the agreed environments.
Review the next decision
NIST SSDF can inform secure development practices during the transition. My recommendation is to present architectural choices alongside dependencies, transition risks and evidence gaps. I personally conduct the review and prepare the findings, so the sponsor can decide what needs to be resolved before proceeding.