Qualify a partner for the change you actually need
Ask a legacy application refactoring company to demonstrate a change to existing code while preserving an agreed behavior baseline. A rewrite partner needs different evidence: how it discovers requirements, implements a replacement and moves consumers safely. Neither engagement should begin with a promise to replace everything before the team can explain the current business workflow.
For an initial interview list, Pharos Production describes incremental extraction, wrappers and parallel operation. Itransition describes approaches spanning refactoring and reengineering. These are published service descriptions, not results from comparable commissioned projects. Ask the assigned team to qualify the exact work rather than choosing from an implied universal ranking. The broader modernization shortlist covers additional providers.
Bound a rewrite by a business capability
Choose one workflow with an accountable owner, inputs, outputs, exception paths and known consumers. A legacy web application can contain behavior in browser code, background jobs, database procedures and operator routines. Include those paths before calling a replacement feature-complete.
Define what will be preserved, intentionally changed and retired. For example, replacing an order-entry screen also requires decisions about corrections after invoicing, duplicate submissions and reports consuming the resulting records. A list of visible screens is a weak scope definition for replacing outdated business software.
Choose refactoring, staged rewrite or product replacement
| Path | Use when | Evidence that could reject it |
|---|---|---|
| Refactor | Existing behavior and platform remain useful, but internal structure blocks change | The required capability cannot fit the supported runtime or data contract |
| Staged rewrite | A capability needs a new implementation while the business keeps running | No viable coexistence boundary or controlled authority switch |
| Buy a replacement | A supported product fits the required process with acceptable extensions | Essential exceptions, integration or export paths fail the fit-gap test |
| Full replacement at once | Coexistence is impractical and the transition can be explicitly bounded | An untested consumer, data gap or unacceptable interruption remains |
Refactoring changes implementation structure under a behavior contract. Reengineering can change a wider system. A modular monolith may be a sufficient target. Use incremental extraction when it reduces a specific transition risk, rather than treating microservices as a required destination.
Download the evaluation worksheet and record the owner, evidence and decision for each row. Its review fields are blank; it is a reusable template, not a completed assessment.
Discover business rules with examples and owners
Request a dependency map, code and support-lifecycle inventory, representative production-shaped inputs and a list of unknown rules. Interview operators about manual corrections and reconcile reports against the transactions that produced them. Characterization tests document observed behavior. A domain owner must decide whether an observed defect should be preserved or corrected.
When documentation is missing, commission a bounded discovery phase with reviewable outputs before committing to a full implementation estimate. Record confidence and unresolved dependencies per capability. A code conversion tool cannot establish which undocumented behavior a customer still relies on.
Require a pilot packet before expanding the rewrite
The pilot should include a repeatable behavior baseline, expected differences approved by the business, identity mapping, data reconciliation and a cutover rehearsal. Compare exception paths and business totals as well as successful API responses. A parallel run needs rules preventing duplicate external effects.
Define the authoritative writer before and after cutover, the supported rollback state and the handling of intervening writes. Feature parity means accepted business behavior under a named scope, not matching page counts. The expand-contract guide examines compatibility when old and new clients coexist. A zero-downtime commitment additionally needs evidence for the actual deployment and data operations.
Compare the same pilot and handover obligations
Ask each candidate for its proposed technical lead, discovery assumptions, customer participation and acceptance evidence. Separate fixed-price scope from unknown investigation. Time and materials should have spending visibility and a continuation decision after the pilot. Include data migration, support during coexistence and retirement in the cost comparison.
The handover packet should identify source rights, third-party licenses, customer-controlled accounts, build steps, infrastructure definitions and operational documentation. Require your team to reproduce a release. A timeline should show prerequisites and acceptance gates rather than an unsupported duration for an unseen codebase.
Make the existing stack a qualification test
For AngularJS, PHP, Java, .NET Framework, Rails or a desktop-to-web transition, provide the exact runtime versions, dependencies and client constraints. Ask the proposed engineers to inspect a representative change and explain the supported destination. A frontend rewrite does not automatically replace backend rules. A runtime upgrade does not automatically fix the business workflow.
This framework is for selecting and scoping a partner. It does not provide migration commands or imply that every candidate supports every named stack. Reject a proposal that substitutes framework enthusiasm for evidence about your application.
Sources
Documentation checked .
Continue the conversation
Comments (0)