The Done-It-Before Migration Playbook: Merged Diffs to a Contract Slate

This playbook is for engineering managers, technical founders, and technical sourcers who have a time-boxed migration to run (AngularJS to React, webpack to Vite, .NET Framework to .NET 8) and need two or three engineers who have finished that exact job before. It uses the migration artifact itself as the search key: a merged manifest diff that removes the old dependency and keeps it removed. You end with a contract-ready slate of 3 to 8 people, each graded Led, Contributed, or Tourist with a dated evidence link, in about five working days.

Why profile keywords fail when you hire an engineer with migration experience

Profile keywords tell you who claims both stacks. They do not tell you who finished moving a codebase from one to the other, and they get thinner the newer the migration is. A repo history either shows the old dependency removed or it does not. A headline can't show that either way.

In Refolk's index of professional profiles, I counted people who list both the source and target skills and also put "migration" in their headline:

The ratios come from the counts: the US AngularJS pool is 7.1x the UK pool and 41.2x the US Webpack/Vite pool.

Two things follow from this.

• For older migrations, keywords give you volume without proof. 412 people is a sourcing list, not a shortlist. Nothing in that count separates the person who led a cut-over from the person who kept a half-migrated hybrid running for two years.
• For newer migrations, keywords give you almost nothing. Ten US profiles is too few to source from. One plausible reading, which is not established, is that people add older skills to their profiles first, so profiles lag the work. Either way, repo evidence is the only search key you can use for the newer pairs.

Look at the top titles too: Staff Software Engineer and Senior Software Engineer, not "migration consultant". The people who did this work describe themselves by their level, not by the job. That is the gap Refolk is built to close. You ask for the engineers who authored the merged PR, not the ones whose headline happens to mention both stacks.

Listing both stacks proves exposure. A manifest diff that removes the old package and stays that way proves completion.

What counts as proof that a migration finished

A migration is proven finished when the project's manifest shows the old package removed and the new package present, and the old package is still absent 90 days later. Anything less proves exposure or an attempt, not completion.

A manifest is the file that declares a project's dependencies: package.json for npm projects, a .csproj file for .NET, a requirements file for Python. A token is the exact package name as it appears in that file, such as angular or webpack going out and react or vite coming in.

Each condition proves something different, and each one can mislead you:

• Old token removed. This proves the team actually cut the dependency rather than adding the new one next to it. It misleads when the token has moved into a second manifest in the same repo, so check every manifest, not only the root one.
• New token present. This proves the target stack is in use. On its own it misleads, because a greenfield repo has the new token without ever having had the old one.
• Holds for 90 days. This proves nobody reverted the migration. It misleads when the repo went quiet right after the change. A removal that held only because nobody committed again is weaker evidence than one that held through active development.

A repo with both tokens at HEAD (the latest commit on the default branch) has stalled. It has not finished. The common example is a hybrid ngUpgrade-style setup, where AngularJS and the new framework run side by side. The engineers on it may be excellent, but they have not yet done the part you are paying for: the cut-over, where the old framework is finally deleted.

Which search surfaces can see a completed migration

Commit search and merged-PR search are the only built-in GitHub surfaces that see history, so they are the ones that find finished migrations. Code search and package datasets can back up the evidence but cannot find it, so use each surface only for what it can do.

The GitHub REST search documentation sets the limits that shape your queries:

• Each search returns at most 1,000 results, at up to 100 per page.
• Each query searches up to 4,000 repositories that match your filters.
• A third-party code search tool documents a maximum query length of 256 characters and warns that GitHub may silently truncate full result sets.

Code search has a caveat I could not verify. It may index only the current default branch. If so, it can confirm the replacement is present but can never show that the old dependency was removed. You can check this yourself: take a repo you control where you removed a package months ago and code-search for that package name. If nothing comes back, treat code search as showing present state only.

The datasets date things. They do not prove anything. GH Archive's BigQuery copy updates every hour, has timeline data from 11 March 2012, and organises its tables by year, month, and day. It records events, not file diffs, so it can date a PR merge but cannot read the manifest. deps.dev covers Cargo, Go, Maven, npm, NuGet, PyPI, and RubyGems and lets you look back over time, but it only includes software published to those registries. Most migrations happen in unpublished applications, so deps.dev helps with library migrations, such as a library dropping Python 2 support, and not much else.

is:pr is:merged migrate webpack vite created:YYYY-MM-DD..YYYY-MM-DD
is:pr is:merged "migrate to vite" created:YYYY-MM-DD..YYYY-MM-DD
is:pr is:merged angularjs react migration created:YYYY-MM-DD..YYYY-MM-DD
is:pr is:merged "remove angular" react created:YYYY-MM-DD..YYYY-MM-DD
is:pr is:merged migrate ".NET Framework" ".NET 8" created:YYYY-MM-DD..YYYY-MM-DD
"migrate to vite" committer-date:YYYY-MM-DD..YYYY-MM-DD

The five-day procedure from migration pair to slate

Seven steps take one from-to pair to a graded, dated slate in about five working days. The order matters: confirm that a migration finished before you grade anyone who worked on it.

The time adds up to five to five and a half days. The work splits across three roles: the hiring manager owns the tokens, the sourcer owns search and confirmation, and an engineer or the engineering manager owns attribution and grading. Founders or legal take the last step.

A few notes on the steps that tend to slip:

• Step 1 is the whole search key. If the tokens are vague ("frontend modernisation"), every later step gets noisy. Two columns of exact package names is the deliverable.
• Step 2 stops at 100 repos. More candidates do not buy more proof. If you are past 100, narrow the date window or add a second token, and don't read further down the list.
• Step 3 is where most candidates drop out. Expect hybrids, reverts, and greenfield repos. That is the funnel doing its job.
• Step 6 is the slowest manual step. Commit emails are often personal or no-reply addresses, and handles rarely match profile names. Refolk resolves this by connecting the public GitHub graph to the open web and LinkedIn in one plain-English ask, so this step doesn't need its own day.

Practitioners don't publicly disagree about this order. The one deviation I see is grading people before confirming completion, which spends a day on authorship tables for migrations that never finished.

How to grade Led, Contributed, or Tourist

Grade each person on two separate axes: their share of migration commits and their role in reviewing migration PRs. Write the thresholds down before you look at any names. The research supports scoring authorship and review separately, but nobody has published cut-offs for "led a migration", so the ones below are Refolk's own.

What the research supports

• Authorship can be measured per file. Avelino et al.'s truck-factor algorithm (ICPC 2016) identifies file experts with a Degree-of-Authorship (DOA) model. One implementation documents author thresholds of 0.75 and 3.293, tuned against git blame. The method was validated by surveying developers of 67 popular GitHub projects.
• Most repos are concentrated. The same line of work found that roughly two-thirds of 133 popular repositories had a truck factor of two or fewer. A truck factor is the number of people who would have to leave before a project stalls. For you, this means most migrations will have one or two dominant authors, which is why "Led" is usually findable.
• Review counts as expertise. JetBrains researchers extended bus-factor work to include code reviews, VCS data, and meetings data. That supports scoring review separately instead of ignoring it.

What the research does not settle

There is no published numeric threshold for "led a migration" that includes review or approval roles. DOA supports per-file expertise, not these grades. The thresholds below are working proposals: use them, write down every exception, and adjust them over time.

The cut-over PR is the pull request that removes the old token from the manifest. Authoring it is strong evidence on its own, because that is the change that commits the project to the new stack.

Repo:
Migration commit range: <first migration commit> to <cut-over merge>
Cut-over PR (removes old token): <link>  merged <date>
Person: <handle>

Migration commits authored, bots excluded: __ of __ = __%
Co-authored-by trailers credited: __
Migration PRs authored: __
Migration PRs reviewed or approved: __
Author of the cut-over PR: yes / no

Led         = 50% or more of migration commits, OR author of the cut-over PR
Contributed = 10% to 49% of migration commits, OR reviewer on 3 or more migration PRs
Tourist     = below both

Flag for interview: reviewed most migration PRs but authored under 10%
Grade:

How migration evidence goes wrong

Most bad slates come from eight failure modes, and each has its own check. Run every check before a name goes forward, because each one produces a convincing false positive.

1. The code-search false positive

The repo has the new dependency but never had the old one, or still has both. A hybrid ngUpgrade-style setup has stalled. It has not finished. Check: confirm in the manifest diff that the old token is gone at HEAD and stays gone for 90 days.

2. Blindness from the result cap

Broad queries hit the 1,000-result cap, and GitHub may truncate them silently. The repos you never see are not random: they are whatever fell past the cutoff. Check: split queries into created: date windows until each one returns fewer than 1,000 results.

3. Attribution after a squash merge

One maintainer merges everyone's work, so commit share makes the merger look like the lead. This is the most common way a Led grade goes to the wrong person.

4. Inflation from bots and codemods

Renovate and Dependabot commits, or a single automated codemod commit, inflate line share. Check: exclude bot accounts and weight by PR count rather than lines. AI-generated code adds a related problem: line-based authorship measures rest on a single inference, that authoring code means understanding it. When a large share of the diff looks generated, use the first call to test understanding instead of trusting the share.

5. Leads who only reviewed

Senior people who approved every PR but wrote little code get graded Tourist if commit share is the only measure. Check: score review role separately. The Contributed threshold of 3 or more reviewed migration PRs exists for this case.

6. The profile-keyword trap

Only 10 US profiles in Refolk's index list Webpack, Vite, and "migration" together. Keyword search misses people whose proof lives in their repos, and it pulls in people who claim both stacks without finishing anything. Check: never let a profile keyword stand in for a dated diff.

7. Consultancy employees

You may not be able to engage these people directly. Check: look at the terms of their current employment before you contact them, and be ready to go through the firm instead.

8. Misclassification

A signed contractor agreement does not settle worker status. Under California's ABC test, the courts and the Labor Commissioner will ignore the contract and apply the test. Check: run the classification step before you make an offer, not after.

Rates, classification, and first contact

Price the engagement against published contract medians, check classification before the offer, and open the first message with the evidence you found. Rate data for migration contractors specifically is not published, so you are pricing from a nearby benchmark.

Rate benchmarks

ITJobsWatch publishes UK medians from advertised contract rates:

Limits to keep in mind:

• These are medians of advertised rates over rolling six-month windows, and the periods do not line up across rows. Re-check the live page before you quote a number.
• I could not find a published rate survey specific to migration contractors, or a US government source for contractor day rates. For US engagements, you need your own benchmark.
• The title changes the price. The UK React median fell from £550 to £500 between periods, while IT Consultant sits at £550. A role advertised as "migration consultant" may price above one advertised as "React contractor". This is an inference from two tags, not a measured premium.

Classification features to check

California's ABC test sits in Labor Code § 2775, enacted by AB5 and codified effective 1 January 2020. The hiring entity has to prove all three of:

1. The worker is free from its control and direction.
2. The work is outside the usual course of the hiring entity's business.
3. The worker has an independently established trade or business.

The test covers any work performed in California, wherever your company is based. Two features of a migration engagement matter most:

• An end date helps. A continuous relationship with no reasonably planned or estimated end points toward control. Write the deliverable (the old token out of the manifest) and an end date into the agreement.
• Core product work fails Prong B. If the migration is your product, the second prong is hard to meet. Take legal advice before you choose between a contract and a fixed-term hire.

I have not re-verified the IRS common-law test (behavioral, financial, relationship) or the UK IR35 off-payroll rules here. Read the IRS independent contractor guidance and the GOV.UK off-payroll working guidance directly for engagements outside California.

Subject: Your <old> to <new> migration in <repo>

Hi <name>,

I found the cut-over PR you authored in <repo> (<PR link>, merged <date>). It removed <old token> from <manifest>, and it has stayed out since.

I have the same migration to run: <one line on codebase size and shape>, in a fixed window of <weeks>, ending <date>. I am looking for someone who has done the cut-over before, on a contract basis.

Would you be open to a short call this week to talk through how yours went? If you are not taking contract work, a pointer to anyone else who worked on that migration would help just as much.

<your name, role, company>

The last line of the message matters. Migrations have one or two dominant authors, and the Led person often knows exactly which Contributed engineer handled the hard parts.

Keeping the slate current

Re-run the search for each new migration pair and refresh a standing slate before you reuse it. New completions keep appearing in public repos, and nobody has published how the pool changes with time since end-of-support.

AngularJS was deprecated after a long-term support period on its final version, 1.8.3. Vue 2's final release is 2.7.16. For the unverified rows, check endoflife.date, python.org, and Microsoft's lifecycle pages, and record the date you checked. To recompute the months column, count from the EOL date to today.

Demand for older pairs does not disappear when support ends. One commercial support vendor estimates AngularJS still powers over 1.2 million live websites. Treat that as a vendor figure, but it is a reason to keep an AngularJS-to-React slate warm instead of rebuilding it from scratch.

To keep a slate usable:

• Re-check the 90-day hold on each person's evidence repo. A later revert or a reintroduced old token downgrades the evidence.
• Re-date anything you rely on against GH Archive. It updates hourly, so new merges are quick to confirm.
• Refresh the rate band from the live median pages before every offer, because the six-month windows move.
• Re-grade when you find new evidence. A Contributed engineer who has since led a second migration moves up.