Every migration I’ve led started with two things: a Proof of Concept, then a Proof of Value. They’re the cornerstone. And honestly, they’re just the fundamentals of project management, done on purpose.
1. Find the motive. When you’re making these changes, start by understanding the motive behind them. There’s a business outcome that needs to be achieved, or somebody’s promotion. Somebody wants this for some reason. They may not tell you, but that’s probably the reason. It’s your job to get curious, uncover it, and turn that ambiguity into something concrete.
2. Write a hypothesis, not just a discovery session. Most people call this step a discovery session. I’d add a hypothesis statement. Think about a time you had an idea of what you wanted to do and why. You still had to test it and validate it to see if it was what you actually wanted. Adoption works the same way, whether it’s a tool or a new framework. It comes from stating the benefits, and from understanding where you’re coming from.
3. Put it in a project charter. Some people call it a PRD (product requirements document), a one-pager, or a business case. They’re different, okay? A project charter has a few key things:
The scope statement: what the project will deliver, how you’ll know it’s done right, and what it won’t include. (The charter holds the why and the when. The scope statement adds the detail.)
The people: the economic buyer, the purchaser, the sponsor, and the key people you need to stay connected with.
The communication plan: how you’ll update people, with what, and why, so everyone knows where the information came from.
4. Answer the five questions that matter.
Who are you?
Who is responsible for the work?
Who’s going to sign the check?
Why are they signing it?
What’s the motive behind signing it?
Put all of that in the document.
5. Go find the pain points. From that document, start reaching out to people to learn what they need, what they want, and what they have problems with. Those are your pain points, and you document every one you can. There are a ton of methods: journey mapping, interviews, focus groups. If you don’t believe me, check out the PMP 8th edition. These are tools in your toolkit, and the expert part is knowing which tool to use at the right time to get you to the result faster. AI can’t do that yet. I’m sure it will, just not today.
6. Build a go/no-go checklist. In the military we had inspections. Every item was a go or a no-go, and there was a pass/fail threshold. With 10 items, you passed at 7 out of 10. At 6 out of 10, you failed automatically. Do the same thing for your adoption or migration evaluation. Now you have a clear path and a clear scope. It stops scope creep, and it’s documented. Everyone understands what you’ll do, when, why, and how you’ll measure success. That’s really all it comes down to, especially on large migrations.
Why this matters more now AI can help you build something super fast, but it’s not always right. It’s getting better, and the better it gets, the more our writing has to keep up. With enterprise tools, the better you write, the better context the AI has when it draws on past work. If you follow this process, anyone who comes after you can read it and understand it. If they hand it to an AI, they can trust what comes back, because what you wrote was thorough and concise: AI-assisted, with a human as co-author. That’s how you move the needle in your direction.
Grab the fill-in template: The Migration Playbook (PDF attached).Change Management
Hit reply: what’s the one document you wish had existed before your last migration?