Offshore transition playbook: four steps to an outcome-based IT model

Twice a year, at contract review, the same conversation happens in IT departments that run offshore delivery. The rates look right on paper. The delivery feels wrong in practice. And nobody can point to the moment it stopped making sense, so the renewal gets signed and the cycle repeats. I have sat in that meeting, on SAP programs where the offshore team was doing real work at a headline rate that looked unbeatable, and I have also been the one who ran the numbers the way they should have been run from the start. The question nobody asks at that meeting is the only one worth answering: if I had twelve months and the mandate to change this, what exactly would I do? This article is that answer, four steps, in the order I would take them.

Step one: audit the work, not the contract

Most transition plans start with the vendor relationship. That is backwards. The contract is a symptom; the work is the cause. Before you renegotiate anything, you need to know what actually flows across the offshore boundary, because the whole case for change rests on one distinction: which of those tickets are translation work, and which are judgment work.

Translation work is a spec going in and code or configuration coming out. A business requirement is already written down, the mapping is documented, and the person on the other side executes it. Judgment work is the ticket that looks finished and is not: the ambiguous requirement, the edge case during cutover, the question of what the business actually meant when it wrote the memo. In my experience of ERP delivery, the split is never clean, and that is the first thing to accept. Some tickets are 90 percent translation, some are 90 percent judgment, most are a mix, and the mix shifts with the system and the phase of the program.

Here is a method that works, and it is deliberately boring. Pull the last ninety days of tickets from the offshore queue. Categorize each one by the dominant type of work: translation, defined maintenance, or judgment. Track the categories for four to six weeks, not one afternoon, because the mix drifts. Then count what each category costs you twice: once at the vendor rate, once fully loaded with the rework, the review time, and the days lost to the timezone gap. You will not need to convince anyone after that exercise, because the numbers will do the arguing.

The research supports this triage more strongly than you might expect. In the randomized controlled trial behind GitHub Copilot, developers completed a bounded coding task 55.8 percent faster with the tool, and the gains concentrated in exactly the well-defined, self-contained tasks that dominate the translation bucket. The economists Brynjolfsson, Li and Raymond found the same shape at scale: in a study of 5,000 customer support agents, generative AI raised average productivity by 14 percent, with a 34 percent lift for the least experienced workers and almost nothing for the most experienced. AI's biggest measured gains land on routine, well-specified work, which is precisely the profile of the offshore ticket queue. That is not a coincidence, and it is the entire strategic basis for the steps that follow.

Step two: move the money from hours to outcomes

Once the audit shows how much of your spend sits on translation work, the second step is to change what you are buying. The standard offshore contract is time and materials: you pay for hours, and the vendor's incentive is to keep the hours flowing. The alternative is to shift as much of the remaining scope as possible to outcome-based or fixed-price SLAs, where you pay for a defined result and the vendor absorbs the cost of their own inefficiency.

If you have never renegotiated a contract like this, set your expectations now, because this is the step where most plans die. Vendors resist outcome-based conversion with real skill, and they have good reason: the time-and-materials cushion absorbs their own rework and overstaffing, and giving it up means their margin depends on execution. Outcome definitions get gamed if they are written carelessly, so the definition of done has to be sharp: what is delivered, how it is verified, what happens when it is not met. And the timeline is longer than a single conversation. Standard notice periods run ninety to one hundred and eighty days, and a real conversion often takes two or three contract cycles to land. This is a multi-quarter negotiation, not a clause you slip in at renewal.

Keep the steps in this order for a reason. If you renegotiate before you audit, you are negotiating blind, because you do not yet know which outcomes are cheap to define. If you renegotiate before you build local capacity, you are shrinking the vendor's incentive at the exact moment you still depend on them. The audit tells you what to move, the local core tells you what you can absorb, and the contract change follows both.

Step three: build the core that orchestrates AI

Here is the step that sounds easy and is not. The idea is simple: a small local team, senior, business-literate, using AI to absorb the boilerplate, the tests, the documentation, and the first-pass implementation of clearly specified features. The execution is where the evidence gets uncomfortable, and you need to know this before you start.

The METR study of experienced open-source developers in early 2025 found they were 19 percent slower with AI on complex, familiar codebases, while perceiving a 20 percent speedup. Read that twice, because it is the single most important finding for anyone planning an upskilling program. Handing your best people an AI tool and expecting speed is not guaranteed to work; on the work they know best, the tool can slow them down while feeling like a win. The perception gap is the trap. Training has to include when not to lean on AI: the complex, context-heavy task where the model's confident answer is a liability, the judgment call where the tool cannot know what the business can tolerate.

The practical consequence is that upskilling is workflow redesign, not tool distribution. The local core learns to split work the same way the audit does: AI takes the defined part, the human takes the ambiguous part, and the review loop is built around checking the boundary between the two. That is a different skill from coding, and it is trainable, but only if the training is honest about the tool's limits.

Step four: pivot the judgment work nearshore, as a bridge

The fourth step is the one most IT directors expect to be the whole plan, and it is actually the most conditional. When full onshoring is not feasible, nearshore teams with real timezone overlap are the natural home for the work that still needs humans: cutover weekends, design conversations, the judgment-heavy delivery that dies across a twelve-hour gap. On SAP programs, this is not a preference, it is a determining factor. A cutover weekend is a sequence of judgment calls about a system running a real business, and the person fixing a failed transport at 2 AM needs context that does not travel in a ticket. Nearshore gives you that context with a sane price.

Treat nearshore as a bridge, not a destination. The same AI dynamics that erode deep-offshore labor arbitrage apply to nearshore teams too; the productivity lift for routine work does not respect geography. A nearshore team is a transitional structure that buys you time while the local core matures, not a permanent solution you can stop thinking about.

The honest part nobody puts in the business case

Every step in this plan is slower and more contested than the checklist makes it sound, and you should hear that from someone who has done it rather than from the tool vendors. The audit is iterative, and misclassifying a judgment ticket as translation will cost you quality at the exact moment you are trying to prove the new model works. The renegotiation is adversarial and takes multiple cycles. The upskilling can make your best people slower before it makes them faster. And the whole thing assumes bandwidth, vendor-negotiation skill, and training infrastructure that many mid-size IT departments simply do not have sitting idle.

That is why this is a twelve-month program with dedicated ownership, not a checklist to run alongside business as usual. If your team cannot give it that, the honest move is to sequence the steps and take them one at a time, starting with the audit, which costs nothing but a few weeks of someone's time and tells you exactly how urgent the rest is.

Eighteen months from now

Here is the picture I keep in my head when I advise on these transitions, because it is a real one. The same team, eighteen months later. The offshore footprint is half of what it was, and what remains runs on outcomes, not hours. The local core is smaller and senior, and it uses AI for the boilerplate without pretending the tool can do the judgment work. The cutover weekend has people in the room who can answer the 2 AM question, because there is no twelve-hour gap between the question and the answer anymore. The program closes on time, and the contract review that used to be a renewal ritual is now a review of delivered outcomes.

You are allowed to run this deliberately, on your schedule, while the money and the momentum are on your side. Start with the audit. The rest follows from what it shows you.

Sources

• Peng, Kalliamvakou, Cihon and Demirer (2023), GitHub Copilot randomized controlled trial
• METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• Brynjolfsson, Li and Raymond (2023), Generative AI at Work (NBER w31161)
• DORA / Google Cloud, State of DevOps 2024
• Everest Group, IT outsourcing research and rate benchmarking