Presenting a Migration Plan to Non-Technical Stakeholders

They Are Deciding Something Else

A plan that persuades your own team can fail in the room where it gets approved, and usually not because it was wrong. Engineers evaluate whether the approach is sound. The people signing it off are deciding whether to accept a risk on behalf of the business, with limited ability to audit your reasoning. Those are different decisions, and they need different material.

This is not about simplifying. It is about answering the question actually being asked, which is rarely "is this the best technical approach" and almost always "what are we committing to, and what happens if it goes badly".

The Three Questions You Will Be Asked

Nearly every question in these meetings reduces to one of three. How long will this take. What breaks if it goes wrong. How will we know it worked. Prepare those three answers properly and the rest of the conversation looks after itself.

The third is the one most plans answer worst, usually with some version of "we will test it thoroughly". That is an intention, not an answer, and an audience that has been burned before can tell the difference.

Give a Range, and Defend It

A single confident date is the most common mistake, and it reads as less competent than a range once anyone probes it. Give a span with the reasons for both ends: the optimistic end assumes the flagged hard objects convert as expected, the pessimistic end assumes they need rewriting and a second rehearsal cycle.

Then say which specific unknown would move you from one end to the other, and when you will know. "We will have converted the three largest PL/SQL packages by the end of week three; if those land cleanly we are at the lower end" gives your audience something they rarely get, which is a date on which the estimate itself improves.

Resist the pressure to collapse the range in the room. A number given under pressure becomes the number you are held to, and you will not be given the context back.

Translate Risk Into Consequence

Technical risks mean nothing to a non-specialist until they are expressed as outcomes. The translation is mechanical once you see it: name the thing that could go wrong, then say what the business would experience.

Technical risk                     ->  What they would experience
---------------------------------      ---------------------------------
Sequence values not advanced past  ->  New orders collide with existing
the migrated data                      order numbers on day one

Date/timestamp semantics differ    ->  Reports silently disagree with
between source and target              last month's figures

A chunked load reports success     ->  The system looks fine and some
while short of rows                    records are simply absent

PL/SQL converted but not reviewed  ->  A month-end process fails at
                                       month-end, not in testing

The right-hand column is what gets discussed. It also makes your mitigations legible, because each one now visibly prevents something specific rather than being generic diligence.

Show Verification as Evidence

"How will we know it worked" deserves a concrete, demonstrable answer, and this is where a plan earns trust disproportionately. Describe the checks in ascending order of strength and be honest about what each one does and does not prove.

Row counts are the cheap first pass and they catch whole-table failures, but they match even when a numeric was truncated or a date lost its time component. Per-row checksums catch content differences. Cryptographic per-partition fingerprints prove a partition is byte-identical. A plan that explains this hierarchy — and says which level it will apply to which tables — sounds like a plan written by someone who has seen a migration go quietly wrong.

Say explicitly that a mismatch is treated as a failure rather than a warning. It is a small sentence that answers a fear your audience may not know how to articulate.

Put It on One Page

Whatever the length of the full document, the decision happens off one page. It needs the scope in counts, the range with its two drivers, the top three risks with their consequences, the verification standard, and the rollback position. Everything else is an appendix for the people who will actually read appendices.

Counts are more persuasive than adjectives. "1,840 objects, of which 1,769 convert automatically and 71 need review" lands differently from "a large but manageable estate", and it invites the useful kind of scrutiny.

Raise the Rollback Yourself

Somebody will ask what happens if you have to turn back. It is much better to raise it first, because volunteering it signals that you have thought about failure, whereas answering it under questioning signals that you had not.

State the cutover decision point, who owns it, what condition would cause you to stop, and what the state of the business is if you do. For a change-data-capture cutover the honest version is usually strong: the source stays authoritative until a human approves the switch, so the fallback is to keep running on the source and try again.

What Not to Claim

Do not bring numbers you cannot defend line by line. Efficiency multipliers, savings percentages and anything that depends on a figure somebody else chose will be the first thing attacked, and losing that exchange costs you the credibility of everything beside it.

Present what you measured, mark clearly what you assumed, and leave out what you merely hope. A plan with three solid numbers and an openly stated unknown is more approvable than one with twenty numbers of uncertain origin.