The short answer
Put the augmented people on the migration and keep your own team on the product. The migration is more definable, which makes it handover-friendly, and product work needs the context only your team has.
The exception is where the migration requires deep knowledge of undocumented behaviour. Then invert it: your team migrates, the augmented developers keep features moving under supervision.
Why migrations suit augmentation
- The end state is definable, often precisely
- Success is testable by comparing old and new behaviour
- The work is finite, so the engagement has a natural close
- It is usually unattractive work that your team is avoiding
- It rarely needs product decisions, which are your bottleneck
The fourth point is worth being honest about. Migration work is frequently postponed because nobody wants it, and bringing in people who are being paid for exactly that is a reasonable answer.
Keep one of yours in charge
The decisions inside a migration are consequential and often irreversible: what to carry over, what to drop, how to handle the data that does not fit the new model. Those belong to someone who will live with the result.
A workable arrangement is one of your engineers owning the decisions and reviewing, with augmented developers doing the volume. It keeps the knowledge and removes the grind.
Sequencing that protects the product
- Freeze the scope of what is being migrated, and write down what is explicitly out.
- Build the comparison harness first, so old and new can be checked against each other.
- Migrate in slices that can be released, rather than one long cutover.
- Keep feature work off the migrated area until each slice is done.
- Agree what happens if a slice takes longer than expected, before it does.
Point two is the one teams skip. Without a way to compare behaviour, every difference becomes an argument about whether it was a bug before or a bug now.
The risk to manage
| Risk | Mitigation |
|---|---|
| Migration knowledge leaves at the end | Your engineer owns decisions throughout |
| Undocumented behaviour lost | Comparison harness catches differences |
| Scope grows quietly | Written scope, explicit out-of-scope list |
| Feature work blocked by migration | Slice releases, area-based split |
| Cutover slips indefinitely | Release per slice rather than one event |
Plan for it ending
A migration engagement has a natural end, which makes handover easier to schedule and easier to forget. Put the handover in the plan at the start rather than discovering it two weeks out.
The thing to transfer is not the code, which you can read. It is the list of decisions taken, the behaviour deliberately dropped, and the parts that were harder than they look.