How to Move From a Failed Offshore Vendor to Pakistan

Changing vendors after a failed engagement is recoverable, and it goes wrong in a predictable way: the new team proposes a rewrite, the buyer agrees, and eighteen months later the situation resembles the original.

What should you do before anything else?

Secure ownership and access. Confirm that the cloud, domain, repository, and third-party accounts are in your organisation's name. Obtain any credentials the vendor holds. Take a full backup of code, data, and infrastructure definitions.

Do this before announcing a transition. Access recovery from a vendor who knows they are being replaced is considerably harder than from one who does not, and this is not a situation where surprise favours you.

What should the first engagement with the new team be?

An assessment, not a plan. Two weeks covering architecture, test coverage, dependency health, security posture, deployment process, data model, and the areas of highest risk, producing a prioritised list with effort and impact.

Assessment area	What it establishes
Architecture	What the system actually does and how
Tests	Whether change is safe
Dependencies	Security exposure and upgrade debt
Deployment	Whether releases are repeatable
Security	Access, secrets, and obvious exposure
Risk areas	Where to be careful first

That document is valuable even if you hire nobody, and it converts a difficult conversation about a failed project into a concrete plan.

Why not rewrite?

Because a rewrite discards working behaviour nobody fully understands, delays value by months, and reproduces the conditions of the original failure: a large commitment made before the problem is understood.

The exception is a system so small that a rewrite is genuinely a few weeks. Everything else should be stabilised and replaced incrementally, using a strangler approach where new functionality is built alongside and the old system retires component by component.

What does stabilising involve?

Getting a deployment path that works reliably, adding tests around the areas you must change, wiring monitoring so failures are visible, fixing the security issues the assessment found, and updating dependencies with known vulnerabilities.

None of this is glamorous and all of it makes subsequent change safe. Teams that skip it spend the next six months breaking things they did not know were connected.

How long does a transition take?

Weeks of reduced velocity while the new team learns the system, shorter with good documentation and a cooperative handover, considerably longer with neither. Plan for it explicitly rather than promising stakeholders business as usual.

The onboarding post covers how to compress the learning period.

What if the old vendor will not cooperate?

Rely on what you own. The repository, the accounts, and whatever documentation you insisted on during the engagement. Where those are missing, the assessment matters more and the timeline lengthens.

This is the strongest argument for ownership terms from day one of any engagement: they are what make an exit possible on your terms rather than theirs. The contract post covers the clauses.

How do you diagnose the original failure?

Honestly, and usually the answer involves your side. The common causes are vague requirements, no written acceptance criteria, no named engineers, code in the vendor's repository, choosing on price against an unclear brief, and nobody technical on the buyer's side able to evaluate the work.

Most of those are within a buyer's control. Naming them is uncomfortable and it is the only way to avoid repeating them.

What controls should the new engagement have?

Written acceptance criteria per milestone, named engineers you interviewed, code in your repository from the first commit, IP assigned on creation, a committed overlap window, documentation as a deliverable, and a bounded first phase before any large commitment.

Those seven address almost every failure mode in the category. The step-by-step post covers the process.

Should you tell the new vendor the full story?

Yes. A candidate who hears an honest account of what went wrong can tell you whether they have handled something similar and what they would do differently. One who is given a sanitised version will price and plan against the wrong problem.

Firms that respond to an honest account with specific questions rather than reassurance are the ones worth continuing with.

How do you manage stakeholders during a transition?

By being specific about the trade-off rather than optimistic about the timeline. A transition costs weeks of reduced velocity in exchange for a system that can be maintained, and stakeholders who understand that trade will tolerate the dip. Stakeholders who were promised continuity will treat the same dip as a second failure.

Give them something concrete early: the assessment document, then a small visible improvement in the first weeks, such as a deployment that now works reliably or a monitoring dashboard that did not exist. Progress that people can see buys the patience the harder work requires, and it is usually available within the stabilisation phase rather than after it.

What does FISTA Solutions do in a takeover?

Starts with a written assessment rather than a plan, stabilises before changing, works in your repository from the first commit, replaces incrementally rather than rewriting, and documents what it learns so the next transition, if there ever is one, is easier than this one.

Related reading: how to vet a software company in Pakistan and legacy modernization services in Pakistan, plus forward deployed engineer.

Secure, assess, stabilise, then change

Four steps in that order. Reversing them is how a recovery becomes a second failure.

Message FISTA Solutions on WhatsApp or start a project to scope an assessment.