01 · Decision guide
Understand what must keep working
Ask business users to demonstrate critical journeys, including month-end tasks, exceptions and workarounds. Map integrations, data ownership and operational dependencies. Code that looks obsolete may encode an essential rule. Start with evidence of how the application behaves, not an assumption that everything needs replacement.
- Identify critical transactions and the cost of failure.
- Document interfaces, scheduled jobs, access rules and data exports.
- Agree a representative regression set with the people who operate the system.
02 · Decision guide
Choose the right change for each part
Retain stable components where there is little business benefit in changing them. Refactor a bounded area when maintainability is the main concern. Replace a component when its constraints justify migration. Integration may solve a workflow problem without a wholesale rewrite. Decisions should include supportability and data transition, not just build effort.
- Retain: acceptable capability, manageable risk and little value in immediate replacement.
- Refactor or replatform: useful business behaviour with technical or operational constraints.
- Replace or integrate: a capability gap that cannot be addressed economically within the current design.
03 · Decision guide
Use AI where its output can be checked
AI-assisted engineering can help draft documentation, suggest test scenarios or prepare code changes for review. Treat those outputs as proposals. Verify generated explanations against the application, review dependencies and test behaviour. Approve tools and data boundaries before sharing source code or customer information.
- Use explicit task boundaries and approved repositories.
- Require human review for code, security-sensitive changes and migration scripts.
- Evaluate a sample of AI-assisted work for correctness, review effort and maintenance impact before extending its use.
04 · Decision guide
Release in increments with a return path
Define acceptance tests, reconciliation checks and rollback conditions before the cutover. A smaller release makes it easier to observe the effect and isolate a defect. Agree who owns monitoring and incident response during the transition, and when the old capability can be retired.
- Validate critical journeys and integrations before release.
- Reconcile migrated data and rehearse the transition where practical.
- Measure failures, user effort, release reliability and support demand after launch.
Bring this to the conversation
A brief that makes discovery useful.
Prepare the following at a high level. No confidential records are needed for an initial discussion.
- Application purpose and critical users
- Main pain points and business-critical journeys
- Integrations, data sources and support ownership
- Desired first improvement
- Access constraints and acceptable transition window
Experience and product fit
Explore the work behind the approach.
ACV’s Gradient story covers software continuity, reports, identity and permit workflows. PLC / PPM4D covers field workflows, document movement, billing logic and architecture planning. Explore these engineering examples, then discuss the continuity requirements and improvement measures for your own application.