Refactor, replatform or rescue? How to decide before a website migration

Your website feels fragile, or the project meant to improve it has stalled. Suppliers recommend different solutions, but you need to decide without becoming a software specialist.

Start by asking what is known, what must work and how change will be checked. A migration may be justified, but it should not carry uncertainty into a larger project. Choose the smallest change that solves the real problem.

1. Regain control before choosing a solution

When releases fail or access is unclear, the whole website can look beyond repair. That appearance is not yet a diagnosis. A broken connection, missing account or uncertain release may be the immediate problem.

Establish who can access the live website, hosting, domain, code, content and connected services. Identify the last stable version and recent release or incident notes. Name one decision-maker and a person responsible for each important system. This is a control exercise, not a hidden rebuild.

If a cyber incident may be active, stop treating the work as a normal migration. ANSSI places remediation alongside investigation and crisis management, so appropriate incident specialists should guide the response before ordinary transformation work resumes (ANSSI).

Replace competing opinions with a shared picture. If a supplier cannot explain the current state, the problem and the evidence behind their recommendation, you do not yet have enough to approve a route.

2. Identify what must keep working

Before discussing platforms, identify the business journeys that cannot stop. These may include an enquiry reaching the right person, checkout, login, publishing or data reaching another business system.

For each journey, record what happens now, who owns it and what a correct result looks like. This creates a baseline: a documented starting point for judging change. NIST’s security-focused guidance is not a website migration manual, but its principles of documenting a baseline, controlling change and monitoring the result are useful here (NIST SP 800-128).

You may hear the word parity. In ordinary language, parity means the new or changed website can do the agreed things the business needs at least as well as the accepted starting point. It does not mean copying every old page or preserving every defect. Decide what must remain, what should improve and what can be retired.

Before approval, ask for the access record, last stable release, essential journeys and owners, content and URL inventory, connected services, agreed checks showing that each essential journey still works, and known gaps. If URLs change, Google recommends mapping old addresses to new ones, testing redirects and monitoring the move. It also recommends separating major changes, such as a domain, content-management system and layout change, where possible (Google Search Central). This is guidance, not a promise about visibility.

3. Choose rescue, refactor, replatform or selective rebuild

An owner may need four choices, with different treatments for parts of one website.

• Rescue means restoring control and stability before making a larger commitment. Choose it when access, ownership, recent changes or the current condition are unclear.
• Refactor means improving a limited part of the existing website’s code or set-up while keeping its intended behaviour. Choose it when the platform is still suitable but a defined area is hard to change safely.
• Replatform means moving the required behaviour to a different platform. Choose it when the platform itself blocks a needed change - for example, it cannot connect to a payment or booking service the business requires - and that limit cannot reasonably be removed in place.
• Selective rebuild means replacing only the parts that cannot be made safe or workable, while preserving the rest. Choose it when the boundary and expected behaviour can be stated clearly.

This is IZZY’s decision framework, not a set of universal definitions. A proposal should connect its route to a specific constraint, explain what stays unchanged and show how the result will be tested.

If you searched for “refactor vs replatform website”, remember that those labels describe only two choices. The evidence may point to rescue or selective rebuilding instead.

If you are wondering whether to rebuild or migrate, ask why repair or selective replacement is insufficient. “Starting clean” is not evidence, nor is keeping the platform from habit. Follow the business journeys, connected services, recovery options and quality of what is known.

A failed project can be rescued without pretending earlier work never happened. Preserve what exists, separate usable parts from assumptions and agree one controlled next decision: migrate, make a smaller repair or say “not yet”.

4. Approve change only with tests, responsibility and a safe way back

A credible proposal names the person responsible for each essential journey, the test that shows whether it works and the signal watched after release. It also states who may proceed or stop.

Ask to see representative tests before the main change. Pages loading is not enough. Forms, payments, logins, publishing, search, analytics and connected services need appropriate checks. Compare content, URLs and transferred data with the baseline too.

The plan needs a safe way back. Teams may call this a rollback, meaning a controlled return to the last stable version if a release causes an unacceptable problem. The plan should say who can trigger it, for how long, what happens to new information and how recovery will be checked. Sometimes switching visitors, restoring data or correcting the new version is safer than reversing every change; make the route explicit.

Do not approve a launch date while access, responsibility, testing or recovery is “to be confirmed”. Proceed when evidence gaps are visible, accepted by named people and matched with stop conditions.

Conclusion

You need not choose on instinct or referee suppliers. Regain control, define what must continue, choose the smallest justified route, and approve it only when tests, responsibility and a safe way back are clear. Migration is one answer, not the starting assumption.

Frequently asked questions