Nearshoring Without Losing Knowledge: What Has to Be Captured Before Cut-over

The decision is usually made in a steering committee, and it is well founded: labour costs, availability of skilled staff, a site closer to the customer. What rarely sits on the table in that meeting is a plan for how the knowledge moves. The processes are in the project plan. The knowledge is nowhere.

How this plays out in practice can be described quite precisely week by week. Not every project looks like this, but most of the ones we see follow the pattern.

Twelve weeks before cut-over: the processes get written down

In this phase the outgoing teams work on process descriptions, handover lists and training material for the new site. It is solid work, and it is necessary. It has one bias: what gets described is what happens regularly. The sequence of steps, the systems, the responsibilities.

What does not get described is what an experienced clerk does when a case does not fit the pattern. How she recognises that an invoice should be held back. Which supplier needs a deadline that is in no contract. Whom she calls when the system rejects a posting that is actually correct. 42 percent of job-related knowledge is documented nowhere (Panopto/McKinsey), and in a relocation that is exactly the part that does not travel.

Eight weeks before: the mood turns

At some point everyone involved understands what the relocation means for their own job. Some look for something new, some stay to the end, hardly anyone is as motivated as at the start. That is human, and it is why knowledge capture that only starts now tends to come out thin.

Ask someone to write a manual in this phase and no manual gets written. A conversation in which someone asks specifically about the difficult cases, on the other hand, costs the person half an hour and feels more like recognition than like being processed. An AI-guided interview needs around 30 minutes of expert time and asks its follow-up questions wherever an answer stays vague. How that works is described in the piece on AI expert interviews.

Four weeks before: the shadow phase

Now the new teams work alongside. This is the phase that shows whether the handover holds.

Three observations are typical:

• The new colleagues handle the standard case quickly and cleanly.
• When something deviates, the question goes by chat to the old site, and the answer comes back at once, because someone is still sitting there.
• Nobody writes those answers down, because right now they work.

The shadow phase therefore creates an illusion of safety. It does not show whether the new site manages on its own, only that it manages with support. The difference only becomes visible once the support is gone.

Cut-over day

Technically the day usually goes quietly. Systems are switched, access rights are set, the first cases go through.

The problem does not come on day one.

Four to twelve weeks after: the exceptions arrive

Exceptions have their own rhythm. Month-end close, the quarterly report, the key account with its special rule, the supplier who changes terms once a year. Many of these cases appear for the first time weeks after the cut-over, and by then nobody at the old site is left who knows them. According to Fraunhofer ISI, 7 in 10 reshoring decisions are driven by quality problems. That rarely has to do with missing machines or miscalculated labour costs, and very often with knowledge that did not make the move.

Fairness matters here: not every dip in quality after a relocation is a knowledge problem. Sometimes processes at the new site are simply set up differently, sometimes system rights are missing, sometimes staff turnover on site is higher than planned. We do not know exactly how much of those 7 in 10 cases the knowledge gap accounts for, and we know of no study that separates it cleanly. What we do see is that most escalations in the first weeks trace back to questions one particular person used to answer.

What follows when you read it backwards

Read from the end, the timeline suggests a different schedule for knowledge capture. It belongs in the phase when teams are still motivated, at the start, not at the end. And it follows the exceptions, not the processes, because the processes get written down anyway.

In concrete terms: for every role that moves, first name the three to five situations in which someone gets asked today even though a process description exists. Capture those situations in short interviews with the people who handle them, verify them, and provide them at the new site as a runbook and a short training, in the language people work in there. Omnora provides such content in more than 140 languages for voice-over and subtitles, so translation does not have to be planned as a project of its own.

What this looks like for a specific relocation is shown on the page on nearshoring and offshoring. What happens when knowledge hangs on a single person is covered in the piece on single points of knowledge.

The question worth asking before the next steering committee is short: which three calls will the new site want to make in week six after cut-over, and who will still pick up?