September 19, 2026 · By Randa Vandenack Schilling

I Migrated Real Client Websites to a Platform I Built. Here's What I Learned

Panderr started with a practical problem: I needed a better way to move websites. Building a migration platform was one thing. Trusting it with real client websites was another.

The smooth migrations were encouraging. The harder sites were more valuable. They exposed deeper navigation, unusual assets, platform-specific behavior, missing images, absolute links, and content that did not fit neatly into a template. Those cases showed me where a migration tool has to be intelligent instead of merely fast.

A homepage preview can look right while the migration is still wrong

A recognizable homepage feels like success, but the harder questions live underneath it. Did every important page come across? Do links stay on the new site? Do forms, downloads, search paths, and navigation still work? Are old URLs preserved or intentionally redirected?

Real client work changed my definition of complete. Visual similarity matters, but completeness has to be measured across the whole website.

URLs deserve first-class treatment

URLs may carry backlinks, rankings, bookmarks, customer habits, campaign traffic, and years of history. A migration system should inventory them before reconstruction, preserve them when practical, and create an explicit mapping when they change.

That is why the SEO migration process and migration checklist treat URL mapping and redirects as core migration work.

Assets are a lifecycle, not a download step

Finding an image in source markup does not guarantee it will render correctly on the destination. Assets can be transformed, referenced indirectly, loaded dynamically, cropped for context, or unavailable without access to the original account.

A better workflow has to discover an asset, determine whether it can be retrieved, associate it with the right content, store it, render it in context, and verify the result. When something cannot be recovered, the system should surface that instead of quietly inventing a replacement.

Preservation requires restraint

AI makes it tempting to improve everything. That can be useful during a redesign, but it is risky when the assignment is migration. Real client sites reinforced a rule I care about deeply: do not invent facts, sections, products, policies, prices, or business claims simply because generated output would look fuller.

Understanding the source should come before generation. That principle is behind Panderr's Preserve, Improve, or Redesign framework. The owner should decide how much change is appropriate.

Navigation reveals whether you understood the website

Dropdowns, categories, utility links, anchors, mobile behavior, and old-domain URLs can expose assumptions quickly. If a migration reproduces the appearance of a menu but not its relationships, it has copied markup without understanding the site.

Edge cases are product work

An unusual client site can feel like an exception slowing down the real work. I have come to see the opposite. Every legitimate failure teaches the platform another distinction it needs to understand. The goal is not to patch one site forever; it is to turn each lesson into a reusable rule, test, or capability.

Verification has to be part of migration

A migration should not end when files render. It needs a comparison loop: inventory what existed, reconstruct it, verify what arrived, flag what changed, and make unresolved differences visible. That includes content, URLs, metadata, links, assets, forms, structured data, analytics, and indexability.

The practical checks are collected in The Complete Website Migration Checklist. For the broader process, read the complete website migration guide.

Seamless does not mean pretending migrations are simple

I still want website migration to feel dramatically easier. But seamless should not mean hiding uncertainty or forcing every site through the same template. It should mean doing more difficult analysis automatically, preserving context, surfacing exceptions clearly, and giving the owner control over intentional changes.

What I would tell someone planning a migration now

Inventory before you move. Keep control of your domain and accounts. Preserve valuable URLs and content. Decide explicitly whether you are migrating, improving, or redesigning. Test more than the homepage. Verify links and functionality on the destination. Keep a record of what could not be transferred. And monitor Search Console and analytics after launch.

If you prefer a managed approach, PeachSites explains what a website migration service should actually include.

Real websites are making Panderr better

Panderr exists because I needed to solve a real migration problem. Using it on real client websites has made the problem more nuanced and the product better. Each migration is teaching the system to distinguish what belongs to the website from what belongs to the old platform, what must be preserved from what can be improved, and what automation should handle from what deserves a human decision.

That is the version of website migration I want to build: not a prettier copy button, but a system that understands enough of what you built to help you move it without starting over.