Stalled projects usually share the same shape: scope was underestimated, communication degraded, and both sides stopped trusting the status reports.

Week one of a rescue

• Code review of what has been built, including test coverage and deployment setup.
• Requirements reconciliation — what was agreed versus what exists versus what is still needed.
• An honest completion estimate with assumptions stated.
• A recommendation with options: continue, hand over, or restart, each with a cost.

Handling the incumbent

Rescues go better when the outgoing team hands over cleanly. Preserve the relationship where you can — access to repositories, credentials and undocumented decisions is worth more than the satisfaction of a hard exit.

What to avoid

Do not sign a fixed-price completion before the assessment is done. Nobody can price the remaining work on a codebase they have not read, and a number given before that point is a guess you will pay to correct.

SEO migration work is unglamorous and entirely front-loaded. Almost all of the value comes from work done before the cutover.

Pre-launch checklist

1. Crawl the existing site and export every indexed URL with its traffic and rankings.
2. Map each URL to its new destination — one-to-one wherever possible, and never redirect everything to the homepage.
3. Preserve on-page elements — titles, meta descriptions, headings, canonical tags and structured data.
4. Match or beat performance on the templates that carry your organic traffic.
5. Prepare the redirect file and test it against the crawl export before launch day.

After launch

Submit the new sitemap, watch crawl errors and rankings daily for the first two weeks and weekly for two months. A dip in the first fortnight is normal. A dip that has not started recovering after six weeks means something in the mapping is wrong, and it is usually findable.

Nobody funds a project called “pay down technical debt”. They fund projects that make releases faster and outages rarer, which is the same work described honestly.

Make the debt visible

Produce an inventory: heavy core customisations, unsupported dependencies, missing tests, manual deployment steps, undocumented integrations. For each, record what it costs — hours per release, incidents per quarter, features it blocks.

Prioritise by cost, not by ugliness

Some of the worst-looking code is stable and untouched, and can safely be left alone for years. The debt worth paying is the debt you touch every sprint.

Fund it inside feature work

Attach remediation to the features that pass through that part of the codebase, and reserve a fixed share of each sprint for it. It is slower than a dedicated project and far more likely to actually happen.