Platform Migration Pilot: How to Rehearse Your Switch (and Why Matching Totals Can Fool You)

By Ellis Grant, EdTechKit Editorial

Documentation checked 14 September 2026. A rehearsal plan based on supplier documentation, not hands-on migration or product testing.

Here is a hypothetical migration rehearsal scenario.

Someone runs the import. They check the numbers. The old platform had 1,247 learners. The new one has 1,247 learners. Everyone breathes out. Job done.

Except it isn't. Because hidden in those matching totals could be a learner who never arrived and another who arrived twice. The numbers balance perfectly, and two real people now have a problem.

A platform migration pilot is how you catch that before it reaches your real learners. It's a small, controlled rehearsal using made-up records, run in a safe space, where you check not just how many records moved but which ones, and whether they still connect to the right courses and permissions.

This guide shows you how to run one, step by step.

Download the pilot execution log (CSV). It contains made-up scenarios and expected results, with the actual-result and evidence columns left blank. Every row starts as "Not run". Use harmless test accounts only, and never add passwords, card details or real learner records.

Run the Migration Pilot After Inventory, Before Switching

Think of a migration in three stages.

First, the inventory: listing everything that has to survive the move. Our course platform migration checklist covers that.

Second, the pilot: testing whether a small, representative sample survives the way you expect. That's this guide.

Third, the switch-over: moving everyone for real, but only after the pilot passes.

You don't need to rebuild all your tests here. Take the riskiest items from the inventory, the teaching checks from our course platform requirements test, and the access checks from our community permission tests. Copy in only what matters most.

Step 1: Build a Small Cast of Made-Up Learners Who Represent Your Hardest Cases

A good test group isn't random, and it isn't a copy of your real customer data. It's a handful of invented records, each designed to test something that's likely to break.

A compact set might include:

• a current learner on one course
• a learner on two products, bought in different ways
• an alumnus whose old completion must still be findable
• a complimentary enrolment with no purchase behind it
• a cancelled community member whose access should end at a specific time
• a tutor with limited admin rights
• a contact who has unsubscribed and must not become marketable just because their email imports

Give them obvious test IDs, like SYN-L101, SYN-L102 and so on. Save the list alongside your log.

If a case can't be tested safely without real personal data, real payments or a live account, mark it "blocked" and find a safer route, like a supplier demo or documentation review. Don't water down the expected result just to make it pass.

Step 2: Freeze Your Test Data So Every Difference Can Be Explained

Before the rehearsal, write down:

• the time you took the snapshot
• the version of your test data
• the file name (or a checksum if you use one)
• the IDs you expect to see
• the relationships you expect (who's enrolled in what)

Freezing means nothing changes on either side during the test. If something does change, log it as a mismatch rather than quietly updating both sides to match.

For a real migration later, you'll need to agree how changes made after the snapshot get picked up. For this rehearsal, keep the test data untouched.

Step 3: Make Sure the Test Can't Touch Anything Real

Name who can:

• create the test space
• provide the source export
• look at the evidence
• accept exceptions
• make the rollback call

Then confirm the test space can't email real contacts, trigger real billing, expose private community posts or overwrite live records.

If any of that is unclear, stop. This guide isn't asking you to import real learners, take real payments, cancel subscriptions, change domains or delete anything. Those need their own approval and controls.

Step 4: Run the Rehearsal in Six Stages

1. Baseline. Save your test data, expected IDs, relationships, permissions and what "pass" means.
2. Run it. Let whoever's authorised perform the migration, rebuild or demo in the safe space. Record what was actually done.
3. Check the structure. Compare IDs on both sides, check none are duplicated, and check the relationships.
4. Check the journeys. Use the test accounts to try signing in, accessing courses, seeing progress and community permissions.
5. Review exceptions. Log each mismatch, which case it affects, what you'll do, who owns it and the retest result. Never overwrite the first result.
6. Rehearse the decision. Pull the evidence together, apply your stop rules and walk through the rollback decision without touching anything live.

Why Matching Totals Can Still Hide Missing Learners

This is the "aha" moment of the whole process, so let's make it concrete.

Here's a made-up example with just four learners. Both sides have four rows, so a simple count says everything's fine.

Look at what happened. One learner vanished. Another got duplicated and picked up access to a course they never bought. And the totals still matched perfectly, because the missing record and the duplicate cancelled each other out.

In real life, that's one person who can't get into the course they paid for, and another who's got something for free. Neither would show up in a count.

The right answer here is "no-go until fixed and retested". Equal totals only prove equal totals.

Step 5: Record Mismatches Without Rewriting History

For every failed or blocked row, keep:

• the original result and where the evidence is
• what went wrong
• what you'll do about it
• who owns it
• the retest result, in its own column

If the expected result needs to change for a good reason, record who approved the change and why. Changing what "pass" means is a decision, not a successful retest.

Good evidence includes a redacted export, a test log, a screenshot, a screen recording, a record comparison or a signed decision note. Store it somewhere access-controlled. A link with no context is weak evidence, because nobody can repeat the check later.

Step 6: The Go or No-Go Gate

The pilot is ready for a "go" only when every important row is one of these:

• Pass: what you saw matches what you expected, and the evidence is available to whoever approves it.
• Approved exception: the mismatch, who's affected, the interim fix, the communication, the owner and a review date are all written down.
• Not applicable: it's outside scope, with a reason recorded.

Anything "not run", blocked, failed or seriously unknown means no-go.

The decision record should name the approver, the date, the version of the evidence and any conditions. It proves you made a decision on a careful rehearsal. It doesn't prove the full migration will go perfectly.

Step 7: Rehearse the Rollback Decision on Paper

Don't prove rollback by breaking something live.

Instead, run a tabletop exercise. Hand your rollback owner a made-up failure ("half the paid members can't log in") and ask them to name:

• what triggers a rollback
• the deadline for deciding
• their deputy
• who handles communication
• what state the service would go back to

Then note whether the evidence and people they needed were actually available.

This exercise often reveals a gap people hadn't spotted. Reopening the old platform doesn't automatically account for anything that happened after the snapshot: new enrolments, progress, posts, preference changes, payments. Finding that out on paper is far better than finding it out during a real switch-over.

Five Migration Mismatch Types to Check in Your Pilot

Use these possible mismatch types to plan your pilot. Knowing them in advance helps you write better test rows, and helps you recognise what a strange result actually means.

1. Missing records

Someone simply didn't arrive. Often it's an edge case: a learner with no purchase behind their access, an account with an unusual email address, or someone in a group the export didn't include.

What it means: your export or import has a filter you didn't know about. Find the rule, not just the person.

2. Duplicates

The same person appears twice. Sometimes because they bought two products, sometimes because they used two email addresses, sometimes because the import ran twice.

What it means: the new platform may now treat one human as two learners, with split progress and confusing emails. Decide which record is the "real" one before the full move.

3. Broken relationships

The learner arrived, but they're not enrolled in the right course, or they're in the wrong cohort, or their access has the wrong end date.

What it means: names and emails moved, but the connections between records didn't. Counts alone cannot establish that these relationships survived.

4. Permission drift

A tutor can see more than they should, or a cancelled member still has access, or a complimentary learner suddenly looks like a paying one.

What it means: roles and access rules work differently on the new platform. Re-map them deliberately rather than assuming a similar role name means the same thing.

5. Silent data loss

Everything looks fine on screen, but something has quietly gone: quiz attempts, completion dates, an unsubscribe flag, a note on a support record.

What it means: the new platform didn't have a place for that data, so it was dropped without warning. These are the hardest to spot, which is why your test cast should include records that rely on that history.

How Big Should a Pilot Be, and How Long Should It Take?

There's no magic number, but a few principles help.

Size it by risk, not by volume. Ten carefully chosen test records that each cover a different tricky case will tell you more than a thousand ordinary ones. Add a record for every kind of person or situation your inventory flagged as risky.

Run it more than once. The first run finds problems. The second run proves your fixes worked. If you change anything significant after the second run, run it again.

Give it a deadline, but not a fixed outcome. Set a date by which you'll make the go or no-go call. Don't set a date by which the answer must be "go". That's how deadlines turn unknowns into accidents.

Involve the people who'll live with the result. Whoever handles support and finance should look at the pilot evidence, not just whoever ran the import. They'll spot problems that matter to them.

What Supplier Documentation Can and Can't Tell You

Using Podia as an example of reading supplier claims carefully:

Podia's switching page says it moves products, courses, customers and email lists by hand, with limits of up to 50 products on Mover and 150 on Shaker and Earthquaker. It also says active paying subscriptions can't be moved.

Its help article says a paid plan is required, describes migration as a manual support process, and says it can't currently migrate tests or quizzes, pipelines or site pages. Its pricing page lists customer email addresses and free community or membership subscribers among the items moved. Podia's pricing page says to request a refund within 72 hours of the most recent payment; it does not offer partial annual refunds. Its migration help says no portion of the plan payment can be refunded once migration work begins, with no exceptions. Confirm this before authorising the work.

These are Podia's own statements, not our test results. They're useful for shaping your pilot rows. But they don't prove what will happen to your specific records, account and plan. Ask the supplier to confirm the scope, then log what actually happens in your rehearsal.

Platform Migration Pilot: Quick Answers

What is a migration pilot?

A small, controlled rehearsal of your platform move using made-up records in a safe test space, so you can find problems before real learners are affected.

Why aren't matching record counts enough?

A missing record and a duplicate can cancel each other out, so totals match even when someone is missing. Always compare individual IDs and their relationships.

Should I use real customer data in a migration test?

No. Use made-up test records designed to cover your trickiest cases. If a case can't be tested safely, mark it blocked and find another way to verify it.

When is a migration ready to go ahead?

When every important test has passed with evidence, has an approved exception, or has been ruled out of scope with a reason, and a named person owns the rollback decision.

How do I test a rollback without risking my live platform?

Run a tabletop exercise. Give the rollback owner a made-up failure and walk through their decision, deadline, deputy and communication plan.

What Comes Next

Return to the platform migration guides for the wider sequence. If running two platforms at once or paid migration help changes your budget, use the UK course platform cost guide.

Keep your inventory, pilot evidence and switch-over decision separate, each with its own owner and history.

Sources

We didn't run a Podia migration or use a supplier account for this resource. The method and worked example use made-up data.

• Switch to Podia (checked 14 September 2026): https://www.podia.com/switch
• Migrating your products to Podia (checked 14 September 2026): https://help.podia.com/en/articles/11370439-migrating-your-products-to-podia
• Podia pricing (checked 14 September 2026): https://www.podia.com/pricing