Last updated: October 1, 2026
By Tom Kenaley, President and Senior Partner, KORE1
A contractor knowledge transfer plan keeps you from getting locked in when it’s written at signing, names an employee to receive each item, and proves every transfer with a test instead of a document. Most lock-in doesn’t come from a contract clause. It comes from accounts, pipelines, and decisions that only the contractor can reach on the day they leave.
The quote came back at $7,400. Forty hours, the vendor’s minimum to reopen a closed engagement, at $185 an hour, with a start date three weeks out because both of its developers were booked on another client. The change itself was small. A county recorder’s e-filing vendor had retired an API version, and one integration needed to call the new one.
The company asking was a title and escrow firm in Scottsdale, about 120 people. A two-person contract shop had built that integration over seven months, and the engagement ended on good terms, with no dispute of any kind. The code ran on AWS Lambda and was deployed with Terraform out of a GitHub organization, and both the GitHub organization and the AWS account belonged to the shop, because on day one that had been the faster way to get started.
That’s when they called us, looking for an engineer to take the system over. We had a good one, a backend developer coming off a contract in Tempe. He couldn’t start, because there was nothing for him to log into.
That’s what lock-in looks like most of the time, a login and not a clause.
KORE1 has done contract staffing since 2005, so I should say where I sit. We’re often the firm whose contractor is leaving, and sometimes we’re the firm that gets called after somebody else’s did. I’ve watched this from both chairs. What follows is the one-page plan I’d want a client to hand us at signing, a template you can copy, and the tests that tell you whether the knowledge really moved.
What a Contractor Knowledge Transfer Plan Is
A contractor knowledge transfer plan is a written schedule, agreed at the start of an engagement, listing everything a contractor or vendor knows or controls that your company will need after they leave. For each item it names the employee who receives it, the test that proves the handover worked, and a due date.
Read it twice and you still won’t find the word documentation in there.
Most templates you’ll find online are documentation plans. Objectives, scope, a list of knowledge areas, a column headed “method” that says shadowing or wiki, and a timeline squeezed into the last two weeks. They aren’t wrong. They’re built for a different situation, which is an employee changing roles inside a company that already owns everything that person touched. A contractor differs in the one way that matters here. Some of what they built may never have been yours in the first place, and a well-written wiki page doesn’t change whose name is on the account.
So a plan for a contractor has two jobs. Move what’s in their head. Move what’s in their name.
The second job is faster and cheaper. It’s also the one that gets skipped.
The One-Page Plan, Row by Row
Below is the version we send clients, minus the logo. Nine rows. An earlier draft had fourteen, and I cut the five (a communication plan, a RACI chart, that sort of thing) that I’ve watched come back blank on every transition document anyone has ever sent me. The Due column counts forward from the contract start date, not backward from the end. I’ll get to why after the table.
| What Moves | Where It Usually Lives | Proof It Moved | Due |
|---|---|---|---|
| Source code and the build | The contractor’s repository or the vendor’s GitHub organization | An employee clones it onto a clean machine and deploys using only the written steps | Repository in your organization on day one. Test at the one-third mark. |
| Cloud accounts and billing | Whoever opened the account, often the vendor | Your company is the account owner and the payer of record | Day one |
| Pipelines, secrets, and scheduled jobs | The vendor’s CI system, a password manager, a cron job on somebody’s laptop | An employee ships a release and rotates one secret without help | One-third mark |
| Why it was built this way | The contractor’s head | Decision notes in the repository. An employee explains three of them back. | Written as decisions happen, reviewed monthly |
| How it breaks | Chat threads and memory | An employee fixes a staged failure and restores last night’s backup | 30 days before the end date |
| Outside contacts, licenses, and API keys | The contractor’s email address or the vendor’s reseller account | Every license and support contact re-registered to a company address | Day one for anything new, 30 days out for the rest |
| Data and exports | Inside the vendor’s tools | A full export loaded into a system you control | 30 days before the end date |
| Open work and known shortcuts | Tickets, plus whatever never made it into a ticket | A written list walked through in one meeting, each item kept or dropped | Final two weeks |
| Questions after the last day | Nowhere | Paid transition hours written into the contract at the same rate | 30 to 90 days after the end date |
I left one column off so the table would fit on a phone, and it’s the one that matters most. A name. One employee per row. Last year a client’s director of engineering returned ours with “Platform Team” typed into all nine cells, so I wrote back and asked which of the six people on the platform team would be at the keyboard for the clean-machine build in week nine. He named a senior engineer in his next email. I think he slightly resented me for it. The build happened, though.
Now the Due column. Count the day-one entries and you’ll find three, all owed before the contractor has written a line of anything, which is the reason the column counts forward. Rows two and six cost nothing in the first week. In month twelve they cost the Scottsdale firm a $7,400 quote for an afternoon’s change.
Most of the remaining rows hang off two other dates. The one-third mark, which on a six-month contract is week eight or nine, sits early enough that a failed test (and the first one always fails) leaves four months to fix whatever it turned up. The other is thirty days out. Somebody has to decide around then whether to extend, convert, or release the person anyway, so I put both conversations in one meeting. The last two weeks get the open-work list, and that’s all they get. Our playbook of staff augmentation practices argues for pulling documentation forward to week six, and I’d pull the accounts all the way to day one and put them on the contractor onboarding checklist next to the badge and the laptop.
Row four is the hard one, and it gets a section to itself further down.
Lock-In Usually Lives in a Login
When a client tells me they’re stuck with a vendor, I ask the same dull questions before anything else. Whose GitHub organization is the code in? Whose credit card pays the AWS or Azure bill? Who’s listed as the registrant on the domain? Whose inbox gets the renewal notice for the monitoring tool? Four questions. They take a minute. Few can answer all four.
If the answer to any of those is the vendor, that client doesn’t have a knowledge problem yet. They have an ownership problem, and I’ve never seen documentation fix one.
It happens innocently. The Scottsdale shop opened its own AWS account because the client’s procurement team needed three weeks to approve a new one and the project already had a start date. I’ve met a freelancer who registered a payment API key under his personal Gmail address for the plain reason that nobody had issued him a company one. And consultancies like to build on their own internal frameworks, which is quicker for everybody, right up until someone reads what the license says about running that framework after the consultancy has gone.
Each shortcut saved a few days in month one. Then month nine arrived.
- Repositories are the easy part. GitHub lets an owner transfer one to another organization with its issues and commit history intact, so I’ve yet to hear a technical reason to wait.
- Cloud accounts took the Scottsdale firm longest. Moving ownership and billing needed sign-offs at both companies, and looking back it would’ve been far less work to open the account under their own organization and invite the shop in.
- Domains and DNS are where I’d look first. A registrar login in a contractor’s name comes up more often than you’d guess, usually at smaller companies, usually for a domain that matters.
- Then there’s whatever starter code or accelerators the vendor brought along. I ask clients whether they have the license terms in writing, meaning what they can run and modify and hand to a different vendor afterward. Mostly they don’t.
- The person. If everything depends on one named engineer at the vendor and your agreement bars you from ever engaging them directly, that’s a lock too.
Two neighbors of this problem have their own homework. Shutting off what a departing contractor can still reach in your systems is the mirror image of everything above, and we’ve written up revoking a departing contractor’s access separately. Who legally owns the code is a third question, answered by the IP paperwork on a contract engagement and not by whose account it sits in.
Proof Beats Paper
The Scottsdale shop did leave documentation, by the way. A 31-page PDF, nicely formatted, with diagrams. It described a system nobody at the client could log into.
I learned the difference between a document and a test from a community bank in Nashville. Its vendor management officer refused to approve a statement of work for a three-person contract data team until the exit plan was attached as an exhibit. The team was rebuilding the bank’s loan reporting pipeline on Snowflake, dbt, and Airflow, and the engineering manager thought the exhibit was bureaucracy. I was skeptical too. Eleven rows. He signed it anyway, mostly to get the project moving.
In week nine, as the exhibit required, one of the bank’s own analysts sat down at a freshly imaged laptop and tried to stand up the whole environment from the repository while the vendor’s lead watched. The lead said nothing. That was the rule. It failed at step four. The cause was an environment variable that existed on all three contractors’ machines and in nobody’s notes.
Forty minutes to fix. That was week nine, with the person who knew the answer sitting right there, a little embarrassed.
Found in month eleven, with the team gone, the same gap is a production outage and a re-engagement invoice. Scottsdale again.
That exhibit listed five tests, and I’ve borrowed all five since.
- The clean-machine build, the one that failed at step four. Somebody who didn’t write the system deploys it from a fresh laptop using only what’s written down, and every question they have to ask turns into a line in the docs.
- One real release, start to finish, pushed by a bank employee.
- They restored the previous night’s backup into an empty environment. Plenty of teams have never tried it, and the first attempt is often where they learn the backup job has been skipping a table since spring.
- Somebody on staff rotated one secret, which turns out to be a quick way to learn whether anyone knows where the credentials live or what breaks when one changes.
- And the analyst had to say what each of the five largest lines on the cloud invoice was for. She got four.
The vendor’s people stayed quiet through all five. That mattered more than I expected it to, because a helpful expert who answers every question in the moment produces a successful demo and transfers nothing. Our IT project staffing page shows where sessions like these sit in a roll-off schedule for a whole team. And when the person holding the knowledge is an employee, not a contractor, there’s a sharper version of the same idea in running one reporting cycle without them.
The Row That Won’t Fit in a Document
Back to row four, the reasons. When the Scottsdale firm finally got its repository back, the engineer we placed there found a 90-second pause hard-coded ahead of one retry. Nobody at the company could say why it was there. He left it alone. I’m told it’s still in there.
That pause is what row four is for. I used to schedule this row at the end with everything else. It never worked. By the last month half the reasons had been forgotten, sometimes by the person who’d had them.
What I’ve seen work is one plain file in the repository. Whenever the contractor makes a call that a future engineer might second-guess, a few lines go in. An entry might read, “Put SQS between the two Lambdas instead of a direct call, because the recorder’s API throttles at ten requests a second. Revisit if they lift it.” Two sentences. About ten minutes, counting the argument with yourself over whether it’s worth writing down. Over six months the file gets to thirty-odd entries, and I’d take it over the architecture diagram.
The Nashville exhibit tested it by having a bank employee explain three of those entries back, cold, with the file closed. Two went fine. On the third he had the reasoning backwards. He took it well. That got corrected in month three, not discovered in month nine.
Put the Exit in the Contract on Day One
A plan nobody is obligated to follow is a wish. The obligations belong in the agreement, and the cleanest model I know of is thirty-five years old.
Federal contracting officers have a standard clause for this, FAR 52.237-3, Continuity of Services, dated January 1991. It commits the contractor to “furnish phase-in training” and to provide “phase-in, phase-out services for up to 90 days after this contract expires.” It requires a transition plan that sets “a training program and a date for transferring responsibilities for each division of work.” And it says the contractor “shall be reimbursed for all reasonable phase-in, phase-out costs.” Put plainly, the handover is a service the buyer pays for, on a schedule, with a date for each piece of the work.
Bank regulators say much the same in softer language. The Federal Reserve, the FDIC, and the OCC issued joint guidance on third-party relationships in June 2023, and it asks banks to outline, before signing, their plans for the day they need “to transition the activity to another third party or bring it in-house.” It also says a contract can protect the bank’s ability “to change third parties when appropriate without undue restrictions, limitations, or cost.” Which is why the vendor officer in Nashville wouldn’t budge.
Sell software or ship freight for a living and no examiner will ever ask to see your exit plan. So it doesn’t get written.
Europe went further and wrote part of it into law. Under the EU Data Act, which has applied since September 12, 2025, cloud providers have to support customers who switch, and switching charges, egress fees included, go away entirely from January 12, 2027. Nothing comparable covers the two-person shop that built your integration. That one’s on you.
For a private company the translation comes to four short provisions. I run a staffing firm and I don’t practice law, so these are a list for your counsel and not contract language. If you run a contingent program, they belong next to the supplier terms you put in writing first.
Knowledge transfer is a named deliverable with acceptance criteria, the same as any other. In an SOW staffing engagement that means the tests from the earlier section go into the acceptance schedule, and part of the final payment waits on them. The same goes for an AI pilot a contract team is hardening for production.
Everything gets built in accounts your company owns, from the first day. It’s one sentence, and it would’ve saved the Scottsdale firm the whole episode.
Transition help after the end date, for a stated number of hours across 30 to 90 days, at the contract rate. I’ve watched what happens without it. The price of a question in month eight is whatever the vendor says it is.
And a line about people. If you might want to hire or directly engage one of the vendor’s engineers later, the time to learn what that costs is now. It’s negotiable before signing. Afterward it’s just expensive.
How any of it gets enforced depends on what kind of contractor is sitting in the seat.
| Question | Agency Contractor on Your Team | SOW or Project Vendor | Independent Contractor |
|---|---|---|---|
| Who directs the daily work | Your manager | The vendor’s delivery lead | The contractor |
| Where lock-in tends to sit | One person’s head | The vendor’s accounts, tooling, and people | Their head and their personal accounts |
| How the transfer gets required | You assign it, like any other task | A deliverable with acceptance criteria | A deliverable in the agreement. You specify the result, not the method. |
| Who hears first that it’s ending | The staffing firm | The vendor’s account lead | The contractor |
That first column is the simplest, and it’s the one we sell most. When a KORE1 contractor works under your direction, keeping the decision file and sitting silently through a clean-machine build are just part of the job you’re assigning. The second and third columns are harder, because you don’t direct the work and the contract has to do it for you. On the project staffing teams we run ourselves, transfer is already in the closing phase. I’d still write it in.
What It Costs, and When to Skip It
I hear “they should document as part of the job” a lot, usually from whoever approves the invoices. It isn’t free, and what that policy buys is a 31-page PDF.
Here’s how the hours have worked out when we’ve planned it with clients. A six-month engagement at full time is 1,040 of them. Decision notes at ten minutes apiece, three test sessions, the fixes those sessions turn up, and a closing walkthrough come to about 40 hours, a little under 4% of the engagement. At $135 an hour, which sits in the middle of the $108 to $160 range we publish for senior software engineer bill rates, that’s $5,400. Then there’s your own employee’s time on the receiving end. About the same again.
Call it $11,000 all in. Against one $7,400 quote to reopen a closed engagement, three weeks of waiting, and whatever the outage costs while you wait, I don’t find it a hard case to make. I’m rounding. Not by much.
When would I skip it?
Plenty of times. Somebody on a three-week contract clearing a Jira backlog doesn’t need nine rows, and I’d feel silly sending the template. A half-page note does it. I’d also skip most of it for a contractor who sits inside your own repositories and gets every pull request reviewed by your staff, since the knowledge is already moving every day through code review whether anybody planned that or not. The mirror case, contract engineers taking over maintenance from your core team, needs the same plan run in the other direction.
Then there’s lock-in on purpose. If you outsourced the help desk to a managed service because nobody in-house ever wanted to run a help desk, depending on that vendor is the thing you bought, and a nine-row plan to take it back would be theater. What I’d still ask for is the exit price, in writing, before signing. It’s the same question that comes up when weighing staff augmentation against managed services, and it’s a lot easier to get answered during the sales cycle than in year three. A vendor-run capacity team sits between the two, and the same question applies.
One more thing, from the recruiting side. KORE1 fills IT seats in 17 days on average, so the replacement is rarely what holds things up. What the replacement gets handed on the first morning is. We ask every time. When we backfill a seat, the first thing our recruiter asks is what the new engineer will be able to log into and read on day one, and I’d trust that answer over the resume to tell me how long the ramp will run.
Asked at Signing, and Asked Too Late
Realistically, how many hours does a knowledge transfer take?
About 40 hours of contractor time across a six-month engagement, plus roughly the same again from the employee receiving it. That’s decision notes written as the work happens, three test sessions, the fixes those sessions expose, and a closing walkthrough. Clients who cram it into the final week spend about half that. They also tend to call us four months later.
What actually goes on the page?
One page, five columns: what moves, where it lives today, which employee receives it, the test that proves it moved, and the due date. Nine rows cover most engagements, and the table earlier in this article is the whole thing. There’s no objectives paragraph. I’ve never met anyone who read one.
Our contractor leaves in two weeks and none of this exists. Now what?
Ownership moves first: repositories, cloud accounts, domains, and license contacts, because those can’t be fixed once the contractor is gone. After that I’d have them record two or three short walkthroughs of whatever only they understand, and I’d buy a block of transition hours at the current rate before the last day. Written documentation comes fourth. I know that sounds backwards. But a rushed document from someone with one foot out the door is the least reliable thing on this list, and a recording of them doing the task at least can’t leave out the steps they’ve stopped noticing.
Can we require documentation if it was never in the contract?
With an agency contractor working under your direction, yes, you assign it like any other task and pay for the hours. It gets harder with a project vendor or a 1099 contractor, where documentation that wasn’t in the agreement is new scope. That’s a change order. And the vendor knows exactly how strong a hand two weeks’ notice gives them.
Is any of this the staffing firm’s job?
The staffing firm owns the timing, not the content: early warning that a contractor is leaving, an overlap period, and a backfill quick enough that both people share a week or two. It can’t write your runbooks or hold your accounts. That part’s yours. We’d rather quote the overlap at signing than scramble for it in the last week. Most clients never ask.
The vendor isn’t going anywhere. Do we still need a plan?
Long-term vendor relationships are when a knowledge transfer plan is cheapest to set up. A vendor you intend to keep for years has no reason to object to building in your accounts and writing down decisions, and you’ll never have more negotiating room than you do before the first invoice. Vendors get acquired. Lead engineers quit. Budgets get cut. The plan is for the ending nobody scheduled.
Write the Last Day First
When a contract crosses my desk, I look for the end before I look at the rate. Not the termination clause. The part that says what the client will be holding when it’s over. Usually it isn’t there. If yours is missing it too, the nine rows above fit on one page, and a contractor who objects to them has told you something useful.
Staffing a project right now? Or backfilling somebody who’s already halfway out the door? Send us the end date and tell us what the seat owns. We’ll tell you what an overlap would take. We’ll bring the template.
