7 mistakes to avoid when migrating from Wix (I made them so you don't have to)

My first website migration was a disaster.

I broke the client's site for 6 hours. Their contact form stopped working for a week without us realizing. They lost Google rankings that took months to recover.

I'm not proud of it. But I learned from every mistake.

After that rough start, I've now migrated 5 websites successfully. All running smoothly. No downtime. No lost SEO. Happy clients.

The difference? I built systems to avoid repeating those early mistakes. Here are the 7 things that went wrong—and how to make sure they don't happen to you.

Mistake 1: Not backing up everything

What happened

On my second migration (a blog-heavy site), I trusted the platform's export feature. Wix said I could export blog posts as XML. Great, I thought. Easy.

The export worked. Sort of. I got the text content. But:

• All formatting was stripped
• Images weren't included
• Custom fields disappeared
• Categories and tags were mangled

The client had 32 blog posts. I had to manually reformat every single one. What should have been a 15-hour migration became 25 hours.

Why it happened

I assumed the export feature would give me everything I needed. I didn't verify what was actually in the export file until I'd already deleted access to the original.

The fix

Now I back up everything manually before touching anything:

Content backup checklist:

• Screenshot every page (for reference)
• Copy all text into Google Docs (preserves formatting reference)
• Download every image (I use a browser extension for bulk download)
• Export any available data (blog posts, products, etc.)
• Screenshot all settings (forms, integrations, SEO settings)
• Document the URL structure (every page URL)
• Save any custom code or embed codes

Pro tip: Even after migration is complete, I keep the old site accessible (just not connected to the domain) for at least 2 weeks. You never know what you might need to reference.

Time investment: 2-3 hours for a typical site. Worth every minute.

Mistake 2: Breaking SEO (URLs changed)

What happened

This was my most expensive mistake.

I migrated a consultant's website. Everything looked great. Design matched. Content transferred. Site was fast. We launched.

Two weeks later, he called: "My Google traffic dropped 40%."

I'd changed his URL structure. His old site had:

• /services/marketing-consulting
• /about-john-smith
• /blog/how-to-grow-your-business

The new site had:

• /services/marketing
• /about
• /blog/grow-business

Seemed cleaner to me. But Google saw them as completely different pages. All the SEO authority he'd built over 3 years? Gone.

Why it happened

I didn't think URL structure mattered that much. I was focused on design and functionality, not the technical SEO implications.

The fix

Option 1: Preserve exact URLs

The best approach is keeping URLs identical. If the old site was /services/marketing-consulting, the new site should be /services/marketing-consulting. Not cleaner. Identical.

Option 2: Set up 301 redirects

If you must change URLs, every old URL needs a 301 redirect to its new location. In Next.js, this goes in next.config.js:

async redirects() {
  return [
    {
      source: '/services/marketing-consulting',
      destination: '/services/marketing',
      permanent: true,
    },
    {
      source: '/about-john-smith',
      destination: '/about',
      permanent: true,
    },
    // ... every single page
  ]
}

My current process:

1. Create a spreadsheet: Old URL → New URL
2. List every single page (including blog posts)
3. Decide: preserve or redirect
4. Implement redirects before launch
5. Test every redirect with a tool like Screaming Frog
6. Monitor Google Search Console for 404 errors after launch

The recovery:

That consultant's rankings recovered after about 3 months once we added proper redirects. But he lost 3 months of traffic. At his rates, probably €5,000+ in lost business.

Never again.

Mistake 3: The DNS nightmare

What happened

This one still makes me cringe.

I was migrating a small business website. Everything was ready. New site tested and working. Client approved. Time to go live.

I changed the nameservers to point to Cloudflare.

What I didn't realize: the client's email was also running through their domain's DNS. By changing nameservers without configuring email records first, I broke their email.

6 hours of downtime. Both website and email.

For a service business, that's potentially thousands in lost leads. The client was... not happy.

Why it happened

I rushed the DNS change. I didn't fully understand how their existing setup worked. I didn't test before switching.

The fix

My DNS migration process now:

Step 1: Audit existing DNS

• What records exist? (A, CNAME, MX, TXT)
• Who handles email? (Google Workspace? Microsoft 365? Direct hosting?)
• Any other services using the domain? (Verification records, subdomains)

Step 2: Set up new DNS (without switching)

• Add all records to Cloudflare (or new host) while old DNS is still active
• This includes: MX records for email, SPF/DKIM for email authentication, any verification TXT records

Step 3: Test new site on staging

• Deploy to a temporary URL
• Test everything thoroughly
• Get client approval

Step 4: Switch DNS during low-traffic time

• Usually late evening or weekend
• Change nameservers
• Monitor email delivery immediately
• Have rollback plan ready

Step 5: Monitor

• Watch for 404 errors in Search Console
• Verify email is working
• Check all forms submit correctly
• Stay available for 24 hours after switch

Zero downtime since implementing this process.

Mistake 4: Assuming features would transfer

What happened

Migrated a restaurant website. Looked great. Launched. Everyone happy.

Three days later: "Why aren't we getting contact form submissions?"

The form looked like it was working. It had a nice submit button. It showed a success message. But submissions were going... nowhere.

On Wix, forms just worked—they had built-in form handling. On the new site, I'd recreated the form visually but hadn't connected it to anything.

Why it happened

I tested that the form displayed correctly. I didn't test that it actually submitted data somewhere.

The broader problem

Website builders bundle many features invisibly:

• Form handling and storage
• Image optimization
• Gallery lightboxes
• Booking calendars
• Newsletter integrations
• Analytics tracking
• Social media embeds

When you migrate, each of these needs to be explicitly rebuilt or reconnected.

The fix

Feature audit checklist:

Before starting any migration, I now list every interactive element:

Forms:

• Contact form → Where do submissions go? (Formspree, email, CRM?)
• Newsletter signup → What email service? (Mailchimp, ConvertKit?)
• Booking form → What calendar system?

Media:

• Image galleries → How should they display? Lightbox? Grid?
• Videos → Embedded from where? YouTube? Vimeo? Self-hosted?
• File downloads → PDFs, documents?

Integrations:

• Analytics → Google Analytics setup
• Social media → Links, share buttons, feeds
• Chat widgets → What service?
• Payment processing → If applicable

Interactive elements:

• Calculators
• Quizzes
• Maps
• Search functionality
• Filters

For each item: document what it does, how it works currently, and what solution you'll use on the new site.

Test every single one before launch.

Mistake 5: Underestimating time

What happened

"This should take about 2 days," I told a client confidently.

It took 2 weeks.

Not because of technical problems—the build went fine. But I completely underestimated content organization. The client had 8 years of blog posts. Images scattered everywhere. Inconsistent formatting. Broken links to external sites that no longer existed.

Just organizing and cleaning up the content took 12 hours. The actual technical migration was only 8 hours.

Why it happened

I estimated based on the technical work: build pages, set up CMS, deploy. I forgot that content doesn't migrate itself.

The fix

Realistic time breakdown for first-time migration:

For experienced migrators (like me now), this compresses:

What takes the most time:

Content organization: 40% Building: 30% Testing: 20% Deployment and training: 10%

My advice: Whatever time you estimate, add 50% buffer. Especially for your first migration. Things will take longer than you expect. The client will have "one more thing" to add. You'll discover a feature you forgot to account for.

Mistake 6: Not training the client

What happened

Beautiful migration. Fast site. Everything working. Handed it over.

Two days later, my inbox:

• "How do I change the homepage text?"
• "Where do I upload new images?"
• "I tried to add a blog post but it didn't work"
• "Can you change this one word for me?"

For the next month, I was basically an unpaid content editor. Every small change came through me because the client didn't know how to use the CMS.

Why it happened

I assumed the CMS would be intuitive. Tina CMS is simple, but "simple" for a developer isn't "simple" for someone who's never used anything besides Wix's visual editor.

The fix

Training package for every client:

1. Recorded video walkthrough (15-20 minutes)

• How to log into admin panel
• How to edit existing pages
• How to add new blog posts
• How to upload and manage images
• How to preview changes
• How to publish

I record these using Loom. Takes me 20 minutes, saves dozens of support requests.

2. Written quick-reference guide

• Screenshot-based instructions
• "How to..." for common tasks
• Troubleshooting common issues
• My contact info for real problems

3. Live training session (optional)

• 30-minute video call
• Walk through the CMS together
• Client does tasks while I watch
• Answer questions in real-time

4. Support period

• 2 weeks of availability for questions
• Quick responses to "how do I..." questions
• Fix any issues that arise

The result: After implementing proper training, support requests dropped by 80%. Clients feel confident. I don't spend my evenings changing single words.

Mistake 7: Forgetting mobile testing

What happened

Launched a photography portfolio. Looked stunning on my 27-inch monitor. Client was thrilled.

Next day, she messaged: "The site looks broken on my phone?"

She was right. The gallery was overlapping. Text was cut off. The menu didn't work properly. It was embarrassing.

Why it happened

I developed on desktop. I tested on desktop. I showed the client... on desktop. Never once opened it on a phone until after launch.

Given that 60%+ of web traffic is mobile, this was a pretty big oversight.

The fix

Mobile-first development:

Now I develop with browser dev tools set to mobile view by default. Desktop is the afterthought, not mobile.

Testing checklist:

Devices:

• iPhone (Safari)
• Android phone (Chrome)
• iPad (Safari)
• Android tablet
• Desktop (Chrome, Firefox, Safari, Edge)

For each page, check:

• Text readable without zooming
• Buttons/links easily tappable (not too small)
• Images scale correctly
• No horizontal scrolling
• Forms work (keyboard appears correctly)
• Navigation menu works
• Nothing overlapping

Tools I use:

• Browser dev tools responsive mode
• BrowserStack (for real device testing)
• Actually testing on my own phone
• Asking the client to test on their phone before launch

The non-negotiable: Nothing launches until I've personally tested on a real phone. Not browser simulation. A real phone.

What I learned

After 5 successful migrations (and that painful learning curve), here's what I know for sure:

1. Checklists save you

Every migration follows the same process now. I have checklists for:

• Pre-migration audit
• Content backup
• Feature inventory
• DNS configuration
• Testing
• Launch
• Post-launch monitoring

I don't skip steps. Even when I'm confident. Especially when I'm confident.

2. Communication prevents disasters

The client needs to know:

• Realistic timeline (not optimistic estimate)
• What will and won't change
• What to expect during the switch
• How to reach you if something's wrong

Over-communicate. It's easier than fixing misunderstandings.

3. Under-promise, over-deliver

"5-7 days" is my standard timeline. Most migrations finish in 4-5 days. Client is pleasantly surprised. Better than promising 3 days and delivering in 5.

4. Test everything twice

Test once during development. Test again before launch. Test again after launch. Things that worked yesterday can break today.

5. Always have a rollback plan

Until the new site is 100% verified, keep the old site accessible. If something goes catastrophically wrong, you can switch back while you fix it.

6. Document everything

For the client: how to use their site. For yourself: what you did and why.

Six months from now, neither of you will remember the details. Documentation is a gift to your future selves.

My current migration process

Here's how I do it now—after learning all these lessons:

Day 1: Discovery and backup (3-4 hours)

• Audit current site completely
• Document all features and integrations
• Back up all content manually
• Screenshot everything
• Create URL mapping spreadsheet
• Identify technical requirements

Days 2-4: Development (8-10 hours)

• Set up Next.js project
• Build pages using my component library
• Configure Tina CMS
• Implement all forms and features
• Transfer all content
• Set up redirects

Day 5: Testing (3-4 hours)

• Test every page on mobile and desktop
• Test every form submission
• Test every link
• Run Lighthouse audit
• Fix any issues
• Deploy to staging URL

Day 6: Client review (1-2 hours)

• Walk client through staging site
• Gather feedback
• Make requested changes
• Get final approval

Day 7: Launch (2-3 hours)

• Configure DNS carefully
• Switch domain to new site
• Verify email still works
• Test everything again
• Monitor for issues

Post-launch (ongoing)

• Record training video
• 2 weeks of support
• Monitor Search Console for issues

Total: 17-23 hours for a typical 8-10 page site.

DIY vs hiring

If you're planning to migrate yourself, here's my honest assessment:

DIY makes sense if:

• You have 30-50 hours to invest
• You're comfortable with command line and GitHub
• Your site is relatively simple (under 10 pages, basic forms)
• You enjoy learning new technical skills
• You have a backup plan if things go wrong

Hire someone if:

• Your time is worth €30+/hour (30 hours × €30 = €900 in time cost)
• You need the site running reliably for business
• You have complex features (booking, e-commerce, integrations)
• You want it done in days, not weeks
• You'd rather not deal with potential disasters

If you DIY:

• Use my checklist from this article
• Read my technical guide on building for free
• Budget 50% more time than you estimate
• Keep your old site running until you're 100% confident
• Test on mobile. Seriously. Test on mobile.

If you want it done right:

I've made these mistakes so you don't have to. My migration process now has:

• Zero downtime
• Full SEO preservation
• Complete feature parity
• Client training included
• 2 weeks support

€500 for 5-7 day delivery. See my Fiverr service →

Ready to migrate safely?

If you want me to handle it:

5 successful migrations. Zero disasters (after learning the hard way). All clients still running smoothly 6+ months later.

• Complete migration: €500
• Timeline: 5-7 days
• Includes training and 2 weeks support
• Zero-downtime process

See my service on Fiverr →

If you're going the DIY route:

Good luck! Use the lessons from this article. Check out my case studies to see what successful migrations look like.

Have questions about your specific situation?

Contact me. I'm happy to help you think through whether migration makes sense and what to watch out for—no obligation.