Skip to content
FLAVIO COPES
flaviocopes.com
2026

I launched migratingto.dev: exact playbooks for moving between platforms

By

I launched migratingto.dev, a library of versioned migration playbooks with transfer breakdowns, timelines, rollback plans, and verification checks.

~~~

Today I launched migrating to.

migrating to is a library of exact playbooks for moving from one software platform to another.

It covers migrations like:

The launch catalog contains 354 migration paths across 151 platforms.

But the number of guides is not the point.

The point is knowing what you might lose before you move.

Why I built it

Most migration guides are too shallow.

They tell you how to export from one platform and import into another. Then they stop.

But a real migration is not just moving rows from A to B.

You also need to know what happens to URLs, media, permissions, automations, metadata, integrations, history, and all the small behaviors your current system accumulated over time.

Some things transfer cleanly. Some need transformation. Some must be rebuilt by hand. Some cannot move at all.

The source platform documents how to export. The destination documents how to import. Nobody owns the gap between them.

That gap is where migrations go wrong.

A new site can look correct while old URLs return 404. A new CRM can contain every contact while losing consent history. A new analytics platform can collect events while using different definitions. A new storage provider can contain every file while permissions are wrong.

I built migrating to around two ideas:

  1. Know the loss before the first irreversible step.
  2. Prove the result before removing the old system.

Who it is for

migrating to is for people responsible for the result of a migration.

That includes:

You can also use it before deciding to migrate.

The transfer breakdown often matters more than the procedure. It shows whether the destination is a real replacement or just looks similar from the product page.

The site does not move the data for you.

It gives you the plan, the risks, the rollback point, and the checks needed to know the move worked.

How a playbook works

You start by choosing where you are and where you want to go.

Every playbook opens with the important answers:

Then it goes deeper.

Each guide contains assumptions, a transfer breakdown, field mappings, backup instructions, transformations, risks, a phased timeline, stop/go gates, cutover steps, rollback triggers, verification checks, and post-migration cleanup.

The verification section is interactive. You can work through the checks and see how many passed.

Some routes also include reports from people and companies that completed the migration. First-person accounts are preferred. Vendor case studies are labeled clearly.

Every guide shows its source and destination versions, official sources, review date, next review date, and current status.

That status matters.

A guide can be tested, needs review, draft, or retired. I would rather show uncertainty than present old information as current fact.

How I built it

The site is data-driven.

I did not create 354 separate Astro pages. Every migration is a structured JSON document that follows one shared contract.

The shape looks like this:

{
  slug: 'wordpress-to-astro',
  source: 'WordPress',
  destination: 'Astro',
  status: 'tested',
  testedVersions: {},
  sources: [],
  assumptions: [],
  fieldMappings: [],
  backup: {},
  transformations: [],
  risks: [],
  timeline: {},
  cutover: {},
  rollback: {},
  verification: [],
  cleanup: {},
}

Astro loads those files as a content collection. Zod checks the structure during the build.

One dynamic route creates every guide:

export async function getStaticPaths() {
  const playbooks = await getCollection('playbooks')

  return playbooks.map(entry => ({
    params: { slug: entry.data.slug },
    props: { entry },
  }))
}

The shared page turns the data into the transfer breakdown, timeline, risk list, procedures, verification report, related routes, and sources.

This keeps presentation separate from migration knowledge.

It also means I can improve one component and update every guide at once.

The hard part was building a trustworthy catalog

Generating a lot of pages is easy now.

Generating a lot of pages that look authoritative is also easy. That is a problem.

The difficult part was building constraints around the content.

Every live playbook must have at least:

The validator also rejects duplicate routes, duplicate source links, placeholder text, invalid dates, incomplete cleanup steps, and playbooks without blocking verification checks.

At launch, the catalog contains more than 4,000 entries covering what transfers and what does not, 2,800 verification checks, and 800 source references.

Those numbers are not proof that every guide is correct.

They are proof that every guide has enough structure to be reviewed, challenged, and improved.

A migration is directional

Another challenge was the route graph.

WordPress → Astro is not the reverse of Astro → WordPress.

The loss changes. The field mapping changes. The backup changes. The risks and rollback plan change.

Even similar products use different names for the same concepts. One platform has projects, another has workspaces. One calls them contacts, another calls them subscribers. One export includes history, another only exports current state.

So every direction is its own playbook.

I built validation around the graph too. Platform names are normalized, every route must be unique, and every live source has multiple possible destinations.

This also powers the related-route suggestions. If the destination does not look right after reviewing what transfers and what does not, you can compare another path from the same source.

Official documentation is not enough

Official documentation is the starting point.

It tells us what an export contains, which APIs exist, and what the destination accepts.

It rarely tells us what happened when someone tried the complete move.

This is why I added field reports.

I built a separate research ledger for all routes. Sources must describe the exact migration, not a generic product comparison. Summaries are paraphrased, recommendations are attributed, duplicate links are rejected, and vendor case studies are visibly different from independent reports.

If I cannot find a credible report, the section stays hidden.

No placeholder is better than invented experience.

This is a result of my software factory

migrating to is another result of my software factory.

I use a repeatable system made of plans, repository instructions, specialized agent roles, bounded tasks, review gates, and automated checks.

AI coding agents did much of the production work. They helped research platform families, build migration routes, create components, expand the catalog, and check independent parts of the product.

My job was product direction, defining the contracts, splitting the work, reviewing what came back, and deciding what was good enough to keep.

The factory made the scale possible.

It did not make judgment optional.

This project made that very clear. An agent can create another 100 migration pages quickly. The real question is whether those pages deserve to exist and what confidence label they should carry.

The software factory increases output. The schemas, statuses, sources, and review process keep that output under control.

The development stack

migrating to uses the AHA Stack:

The rest is deliberately small:

There is no database, account system, API, or server-rendered application.

The full catalog is generated as static HTML.

The deployment stack

The site is deployed to Cloudflare Pages.

The build command does more than generate HTML:

npm run build

It regenerates the catalog manifest, validates all playbooks, checks the route graph, validates field reports, runs astro check, builds the static site, and confirms every expected route exists in dist.

If a migration file breaks the contract, the deploy stops.

There is no Astro adapter, serverless function, environment variable, secret, or database migration involved in a release.

Cloudflare serves the generated pages and assets. The small interactive parts run in the browser.

How this can evolve

The first job is not adding more routes.

It is reviewing and testing the routes already there.

I want to deepen the most useful playbooks, add more first-hand field reports, keep platform versions current, and make review status more useful over time.

The next layer is migration kits.

The online guides will keep the complete safety information free. A paid kit can package the same work into a polished PDF, an editable field-mapping worksheet, a risk register, a project timeline, cutover and rollback checklists, and a fillable verification report.

For larger migrations, the same system can also support professional planning and execution. The playbook becomes the starting point, then the real account size, constraints, integrations, and acceptable losses shape the project.

I also want demand to guide the catalog.

Searches, requests, and field reports can show which routes deserve deeper testing. I do not want to add pages only because the factory can produce them.

Try it

Open migrating to, choose the platform you are leaving, and see where you can go.

The playbooks are free and do not require an account.

If you completed one of these migrations, found a missing risk, or have a route you want me to add, let me know.

Tagged: News · All topics
~~~

Related posts about news: