Outsourced System Gone Wrong? A Decision Guide to Repair, Refactor or Rebuild

Previous vendor vanished and the system is slow and full of bugs? Learn how to run a system health check, use a decision matrix to choose between repair, refactor and rebuild, and what to prepare — plus contract clauses that prevent it happening again.

The Warning Signs of a Project Going Bad

Outsourced systems rarely fail overnight — the signs accumulate. If two or more of these sound familiar, start preparing your exit now:

• Fix A, break B: every small fix causes two other features to fail, meaning the codebase has become so entangled that everything touches everything.
• Everything keeps getting slower: pages take longer as data grows, revealing a database and architecture never designed for scale.
• The vendor responds slower and slower: instant replies become read-and-ignored; quotes grow larger and timelines longer — they are pricing you out on purpose.
• No documentation exists: ask how a feature works and the answer is "the engineer who wrote it left".
• You do not hold the source code: the code, database and cloud accounts are all in the vendor's name. You are effectively renting your own system.

The worst-case script is waiting until the vendor formally disappears and the system dies — at which point you cannot even assess whether it is salvageable.

Step One: Health Check First, Rewrite Later

Eight out of ten owners burned by a bad system open with "let's just rebuild everything". Pause — a rewrite is the most expensive and highest-risk option, and the old system must keep running your business until the new one ships. The correct first step is a stocktake:

1. Source code: can you obtain it? Is it the current version? Is there version-control history?
2. Database: where is the schema documentation? Can the data be fully exported? Are there regular backups?
3. Deployment environment: whose servers does the system run on? Who holds the credentials? Who registered the domain?
4. Account ownership: payment gateways, SMS, maps and other third-party services — whose accounts, and who pays?
5. Documentation: specs, API docs, user manuals — collect whatever exists.

This checklist doubles as the takeover assessment: the more you can recover, the cheaper the takeover. Only when nothing can be recovered does a true rewrite become the answer.

Repair, Refactor or Rebuild: The Decision Matrix

With the health check done, map your situation onto three routes:

In practice the most common answer is a hybrid: repair first to stop the bleeding, then refactor module by module, and rewrite only the parts that are truly beyond saving. A big-bang rewrite sounds satisfying, but few live systems can afford the gamble.

How a Takeover Team Actually Works: Four Stages

1. Diagnose: read through the code and database schema, scan for quality and security issues, map the technical debt by severity, and produce a health report with a prioritized treatment plan.
2. Stabilize: treat the acute, business-impacting problems first — crashing bugs, saturated bottlenecks, obvious security holes — so the system stops hurting operations.
3. Refactor: rebuild module by module against explicit acceptance criteria, adding documentation and tests along the way, converting the system from "only the old vendor understood it" to "documented and maintainable".
4. Hand over: deliver source code, documentation and account ownership in full, and establish the ongoing maintenance arrangement.

EFFECT's software solutions team has worked through more than 100K lines of inherited code. The sentence we hear most from clients: "so we didn't need to rebuild after all". Most systems given a death sentence are, in fact, salvageable.

What to Prepare for the Takeover Team

• Your health-check results: source code, database, server accounts, domain — what you have and what is missing, listed honestly.
• A problem list: your 5–10 most painful issues with frequency and impact (e.g. "checkout page crashes 2–3 times daily; support receives complaints").
• Business context: which processes the system supports, how many daily users, which functions are mission-critical.
• The original vendor contract: the takeover team needs to know where the IP and source-code ownership boundaries sit.

Making Sure It Never Happens Again

The takeover fixes this crisis; contract and delivery habits prevent the next one:

• Source-code ownership in writing: the contract assigns IP to you, with continuous delivery through version control (e.g. Git) — not a zip file at final handover.
• Hold your own accounts: cloud hosting, domain, database and third-party services are opened under your company's accounts; the vendor works through invited access.
• Staged acceptance: split the project into verifiable phases, with each payment tied to working deliverables — never pay everything upfront on a promise.
• Documentation as a deliverable: specs, deployment docs and manuals are contract line items; no documentation, no sign-off.

System slow, crashing, and the old vendor has gone quiet? Bring your health-check list to EFFECT's free 30-minute consultation — we will tell you straight whether the system can be saved, which route to take, and roughly what it will cost.