If your A/B test history lives in Notion, you’ve probably felt the pain. Tests get logged, but results are hard to compare. Metrics drift. People rename fields. Old pages turn into dead ends no one trusts.
A real experiment library fixes that, but the move can get messy fast. Not because the export is hard, but because “history” in Notion usually isn’t clean enough to migrate as-is.
This guide walks through a practical migration plan: define the new system, map fields, clean the backlog, then handle redirects so old Notion links still help instead of hurt.
Pick the destination and lock your experiment library schema
Before you touch Notion, decide what “real experiment library” means for your team. It could be a dedicated experimentation tool, a database-style workspace (Airtable, Coda), or an internal app backed by Postgres. The tool matters less than the structure.
Your first job is to lock a schema that won’t change every two weeks.
What a useful experiment record should answer
A good library lets someone scan a test and quickly learn what happened and what to do next. Aim for fields that answer:
- What did we change, and where?
- Why did we think it would work (hypothesis)?
- What was the decision metric?
- What was the result, and how confident are we?
- What did we ship (or roll back), and what did we learn?
Keep the schema tight. Every optional field becomes a future blank column.
Minimum fields that age well
Most teams do fine with:
- Experiment ID (immutable, unique)
- Title
- Product area (activation, pricing, onboarding)
- Primary metric (and guardrails if you track them)
- Hypothesis
- Variants summary (control vs treatment, short text is fine)
- Start date, end date
- Status (Draft, Running, Shipped, Stopped, Inconclusive)
- Outcome (Win, Loss, Neutral, Mixed)
- Decision and next step (one short paragraph)
- Owner (person) and stakeholders
- Links to assets (PRD, design, dashboard, feature flag)
Decide naming rules now. If one person writes “Signup CVR” and another writes “Sign-up conversion,” search breaks and reporting becomes manual work.
Map Notion fields to your experiment library (and keep IDs stable)
Notion databases feel structured, but the data inside them often isn’t. Mapping is where you prevent “garbage in, garbage forever.”
Start with an audit, not an export
Open your Notion database and do a quick pass:
- How many properties exist, and which are actually used?
- Are statuses consistent, or do you have five versions of “Running”?
- Are results stored as pages, comments, or random text blocks?
- Are key fields missing on older tests (dates, metrics, outcomes)?
This audit tells you how much cleanup you need before import, and which fields should be dropped.
A simple mapping table (example)
Use a mapping doc so the whole team agrees on what moves and how it transforms.
Don’t migrate without an experiment ID
Notion page URLs aren’t stable identifiers in your new system. Create an Experiment ID that will survive tool changes, like EXP-000312. Add it to Notion first, even if you plan to leave Notion behind.
If you already have IDs, freeze them. If you don’t, generate them, then backfill into Notion so the export includes them. That single step saves you from duplicate imports, broken references, and “Which test is this?” confusion.
Clean up A/B test history so the library is trustworthy
Migration is a rare moment when you can fix years of drift. You don’t need perfection, but you do need consistency.
Triage first, then clean in passes
Split tests into three buckets:
- Recent and high-impact (last 6 to 12 months, big traffic, revenue-impacting)
- Older but still referenced (linked in docs, onboarding, strategy)
- Everything else (archive-grade)
Clean the first bucket deeply. For the last bucket, you can do “good enough” cleanup: status, dates, owner, and outcome.
Standardize the fields people search by
Most teams search an experiment library by metric, area, and outcome. Focus cleanup there:
Metric names: Pick a canonical name list and stick to it. If you track “Activation rate,” define the exact event and denominator in one place, then link to that definition.
Statuses and outcomes: Reduce free-text. A dropdown beats creative writing. If you want nuance, keep it in “Decision notes,” not in the status field.
Dates: If end dates are missing, decide on a rule. Either backfill from launch notes, or mark them clearly as unknown. Don’t guess.
Dedupe and merge without losing context
Duplicates happen when teams re-test similar ideas, or when someone copied a Notion page. When you merge:
- Keep the newest record as the primary entry.
- Add links to prior runs as “Related experiments.”
- Copy over key artifacts (dashboards, screenshots) into the primary record.
Your goal is one canonical place to land, even if the history is messy.
Rewrite weak “learnings” into one clear decision
A good summary reads like a post-game report. One paragraph is enough:
- What changed
- What happened to the primary metric
- What you shipped (or why you didn’t)
- What you’d try next
If a result is inconclusive, say why (low sample size, tracking broke, seasonality). Future you will thank you.
Set up redirects so old Notion links don’t break trust
The fastest way to kill adoption is broken links in old docs, Slack threads, and onboarding pages. Even if your new tool is better, people will bounce back to Notion out of habit.
Build a redirect map using stable IDs
Create a simple redirect sheet:
- Experiment ID
- Old Notion URL
- New library URL
- Owner (who can answer questions)
Even if you can’t do true 301 redirects from Notion, this map becomes your source of truth for updates.
Use “soft redirects” inside Notion
Notion doesn’t give you server-level redirects for public pages. What you can do is:
- Keep the old Notion pages live as stubs.
- Replace the page content with a short “Moved” note and the new link.
- Put the new library link at the very top so it’s unmissable.
- Lock the Notion database to read-only to prevent split-brain updates.
If your team shares experiment links often, consider using a short link pattern you control going forward (for example, go.company.com/exp-312). That way, the next migration won’t hurt.
Update the places that create repeat traffic
After the migration, search for Notion links in:
- Growth playbooks and onboarding docs
- Templates for experiment write-ups
- Roadmaps and quarterly planning docs
Fix the “top 20” first. That usually covers most clicks.
Conclusion
Migrating A/B test history from Notion isn’t a copy-and-paste job. It’s a chance to turn scattered pages into a real experiment library people can search, trust, and reuse. Lock your schema, keep experiment IDs stable, clean the fields that drive decisions, then handle soft redirects so old links still lead somewhere useful.
If your library makes it easy to answer “What did we learn last time?”, your team will stop re-running the same tests and start building on momentum.