How to Protect Your Data During a Website Redesign: A Lossless Data Migration Guide

Website data migration during a redesign means moving customer accounts, orders, form entries, mailboxes and analytics history from the old system to the new one without losing a single record. This guide skips design and page content. Instead, it covers the invisible layer: databases, backups, trial migrations and verification. Since 2012, I have seen the most expensive redesign mistakes happen right here.

What is website data migration in a redesign?

Website data migration is the process of extracting records from the old site's database and connected services, mapping them to the new system's structure, loading them and verifying the result. It covers user accounts, password hashes, orders, form submissions, email and analytics history. In short, the goal is a switch with zero lost records.

I draw a clear line here. Moving page copy, images and URLs is content migration, and I cover the search side in my guide to protecting SEO during a redesign. This article is about the business memory instead. Who bought what, who filled in which form, and which customer logs in with which password.

In short, you can replace the design. However, you cannot replace the history. That history has to move into the new house intact.

Why does data go missing during a redesign?

Data rarely disappears because of bad intent. It disappears because of gaps in the plan. The most common scenario I see goes like this. The team builds the new site on a staging server for weeks. Meanwhile, the live site keeps taking orders and form entries. If you only import the first snapshot on launch day, every record from those weeks falls into a hole.

Also, every platform has its own data model. For example, the old system may store "full name" in one field, while the new one wants first and last name apart. As a result, without careful mapping, names end up cut or empty. Character encoding causes trouble too, and accented letters turn into question marks.

• New records that pile up between the staging copy and launch day.
• Field mapping mistakes and truncated text.
• Encoding mismatches, such as latin1 mixed with utf8mb4.
• Closing the old hosting account too early.
• Data sitting in third party tools that nobody owns.

Therefore, most data loss is a planning failure, not a technical accident.

Which data should you migrate, and how do you build the inventory?

Your first job is a list of every data type the site holds. This is not a list of pages. Specifically, I mean database tables and external services. I usually collect them in a single table and assign an owner to each row.

As a result, no data type stays in the "everyone assumed someone else had it" category. I also suggest adding a column that asks whether the new system has an equivalent field.

How should you back up before website data migration?

A backup is the insurance policy for website data migration, and you need to take it and test it before anything moves. Above all, I never trust a single backup. Instead, I take a full database dump, an archive of the file system and a copy of every mailbox.

1. Export the full database, structure and data together.
2. Archive the file system, especially the uploads folder.
3. Download the backup. A copy on the same server won't help if that server fails.
4. Check the file integrity with a checksum.
5. Restore the backup to an empty environment and confirm that it works.

In practice, most teams skip the last step. That said, a backup you have never restored is a hope, not a backup. Also, don't leave the dump on the server after the project. A database export forgotten in a public folder is a serious leak.

How do you migrate user accounts and passwords?

First, passwords are the hardest part of user accounts. A sound system never stores passwords in plain text; it only keeps a hash. So you can't "read" a password and write it into the new system. You have to carry the hash over, and the new system has to know how to verify it.

Platform changes also make this tricky. For example, according to the WordPress core team, version 6.8 moved from phpass to a bcrypt based method. In other words, the hash format can change even between two versions of the same platform. If you switch platforms, you need a compatibility layer that lets the new system check the old hashes.

If that layer isn't possible, the fallback is a password reset on first login. However, announce it in advance with a clear email. Otherwise, your support inbox will overflow during launch week.

How do you keep order and invoice history intact?

Order data is never a single table. The order header, line items, payment record, shipping details and customer record all link through IDs. Break those links and the order list still looks full. However, no order belongs to the right customer anymore.

So my first rule is simple: keep the old IDs where you can. If you can't, keep a mapping table of old and new IDs, and don't delete it after launch. Months later, when accounting or a refund request needs an old record, that table saves the day.

Next, watch the order number sequence. If the new system starts at 1, old and new orders share the same numbers and customer emails get confusing. Instead, make the new sequence start above the highest old number. On online stores, I plan these settings from day one as part of e-commerce consulting.

How do you protect form entries and lead data?

In practice, form entries are the most neglected data on most sites. Contact, quote and booking forms often store entries in a plugin's own table. If that plugin doesn't exist on the new site, the table stays behind, and years of leads vanish quietly.

My method is to export every old entry as CSV first, then import it into the CRM or the new form table. That way, entries don't depend on one platform. In addition, I match field names between the old and new forms. For example, small differences like "phone" versus "tel" create empty columns on import.

Launch day also brings its own risk. If the old form still works while the new one goes live, leads can land in two places for a while. So switch off the old form at launch and check any entries that arrive after that moment. For the new form itself, see my guide to booking, quote and demo forms.

What should you watch when moving email accounts?

Above all, email is the sneakiest loss in a redesign. In many small businesses, company email sits on the same hosting account as the website. When the new site moves to another server and the old hosting closes, years of correspondence go with it.

• First, confirm where email lives: on the hosting or with a separate provider.
• Copy mailboxes to the new server over IMAP, including history, not just new mail.
• Write down the current MX, SPF, DKIM and DMARC records before you touch DNS.
• Keep checking the old mailbox for a few days after the DNS change.

You can check current records quickly with the DNS lookup tool. Moreover, separating email from the website removes this risk for the next redesign. I explain that setup in my business email guide.

How do you carry analytics history over to the new site?

Technically, you don't move analytics data at all. Instead, if you set things up right, it simply stays where it is. The rule: don't create a new GA4 property for the new site. Instead, keep the existing property and measurement ID. That way, before and after sit side by side in the same report.

Still, mind GA4's retention settings. According to Google Analytics Help, standard properties keep event level data for 2 months by default, and you can extend it to a maximum of 14 months. In practice, this setting affects explorations. If you want long term comparisons, I suggest turning on the GA4 BigQuery export before the redesign.

Don't forget conversion events either. If form or purchase event names change on the new site, the conversion goals in your ad account stop receiving data. Keep event names exactly the same as before.

What happens to Search Console and ad account data?

Search Console data belongs to the domain. If the domain stays the same, past performance data stays too. If the domain changes, verify both the old and new properties and use the Change of Address tool. I walk through it in my Search Console guide.

On the ads side, the real risk is missing conversion tags on the new site. With no tag, the ad account sees zero conversions for days. Smart bidding then reads that gap as "ads don't work" and lowers bids. For that reason, I test tags on staging with Tag Assistant before launch.

On the other hand, remarketing lists depend on cookies as well. Keep the tag and the lists keep growing without a break. Change it and they refill from zero.

How do you map fields when the database structure differs?

A field map shows where each old column goes in the new system. I build it in a spreadsheet before anyone writes code. The left column holds the old field, the middle holds the new field, and the right holds the conversion rule.

For example, if the old system stores phone numbers without a country code and the new one requires it, you write that rule up front. The same goes for date formats, currencies and status codes. If "3" meant "shipped" in the old system, define its new equivalent explicitly.

Some fields have no home in the new system. Instead of dropping them, I keep them in a notes field or a separate archive table. A field that looks useless today may become the only evidence in a customer dispute six months later.

In short, the field map becomes both the developer's roadmap and the document you check when questions come up.

How do you prevent encoding and format problems?

Encoding mismatches are the most common corruption I see on multilingual sites. A name like "Müller" turns into "Müller". This usually happens when export and import use different character sets.

So I set the character set explicitly when I export, and I create the new database with utf8mb4. utf8mb4 stores the full Unicode range, emoji included, while the older utf8 setting in MySQL can cut some characters. After the import, I open a few records with accented names and check them by hand.

Format problems go beyond letters. The decimal separator is a classic trap: many European countries use a comma, while most software expects a dot. If the price field is misread, an order of 1.250,00 can appear as 1.25. Therefore, always verify amount fields with a total check.

What about data in third party services?

A modern website is more than its own database. The newsletter list lives in an email platform, chat history in a support tool, reviews on a review platform and payment records with the payment provider. A redesign can break these connections.

• Newsletter: export the subscriber list and keep the consent records.
• Payments: update callback and webhook URLs for the new site.
• Live chat and support tools: export past conversations.
• Shipping and accounting integrations: set up API keys and endpoints again.

Also check whose name these accounts sit under. An account tied to a former agency or an employee who left turns into an access problem mid project. So I suggest moving every account to a company owned address.

Why should you run at least one trial migration?

A trial migration moves a copy of real data into the new system as a rehearsal. I run at least one on every project, usually two. The first finds the errors. The second proves the fixes actually work.

During the trial, I focus on related records. Are a customer's orders, addresses and reviews still linked to the same customer? If you can't answer yes, don't move on to the real migration.

The trial has another benefit: you measure the time. A large database can take hours to move. Without that number, you can't predict how long the site will be down on launch night.

Also, keep staging closed to the public. A staging site with real customer data that search engines can reach means duplicate content and a personal data leak. Protect it with a password; the password generator does the job. Where possible, mask personal fields in the trial copy.

How do you verify website data migration afterwards?

I verify with numbers, not with my eyes. Before the move, I count records in every table on the old system. After the move, I repeat the count on the new one. If the numbers don't match, the launch waits until I find the gap.

1. Record counts: customers, orders, forms and reviews, table by table.
2. Totals: does the sum of all order amounts match on both systems?
3. Samples: open the history of 20 random customers by hand.
4. Edge cases: the oldest record, the newest record, names with accents.
5. Function tests: log in with a migrated account and open an old order.

Put simply, "the site loads" is not verification. Website data migration isn't done until the numbers match on both sides. A written checklist also gives the client a transparent handover report.

How do you plan website data migration on launch day?

The core of the launch plan is the delta migration. After the trial copy, the old site keeps creating records, and you need to move them at launch. The cleanest way is a short maintenance window.

• Pick the lowest traffic hour; your analytics data shows it.
• Pause orders and forms on the old site.
• Move the delta and repeat the count check.
• Only then switch DNS or the server routing.
• Keep the old system online in view only mode for a while.

Lowering the DNS TTL a day before helps the change spread faster. After that, check your URL redirects with the redirect checker. For the full URL side, see my website migration SEO checklist.

What is your rollback plan if things go wrong?

A rollback plan is a written list of steps for returning to the old system if a serious data issue appears after launch. I write it before launch day, because panic makes good decisions hard.

The plan needs clear answers to three questions. First, what triggers a rollback? For example, payments fail or a large share of customers can't log in. Second, who approves it? Finally, how will you rescue records the new site created in the meantime?

Teams often forget the last question. If the new site ran for a few hours, orders from those hours live in the new database. So a rollback has to move them back too. That is one more reason not to delete the old system right away.

That way, when something breaks on launch night, you follow the list instead of arguing.

When is it safe to shut down the old system?

Shutting the old system right after launch is one of the costliest habits I see. A missed table usually shows up weeks later. A customer asks for an old invoice, or a colleague needs an old email thread.

So I suggest keeping the old system in view only mode for at least a few weeks. That is a starting range based on field experience, not a guarantee. Set the hosting contract end date accordingly. Before shutdown, take one final full backup and download it to company storage.

Also, personal data on the old server needs attention after shutdown. Ask the hosting company to confirm that the account and its backups are gone. Otherwise, customer data keeps sitting on a server you no longer use.

What does GDPR mean for website data migration?

Moving personal data is also a legal act. If a new host, software company or agency will touch your data, put the processing terms in writing. Have a legal expert review that part; I only share the technical points I watch.

• Avoid real personal data on staging, or mask it.
• Don't send database dumps as email attachments or open share links.
• Find out where the new server is located and update your privacy notice if needed.
• Apply your deletion policy to old records you no longer need instead of moving them.

Access rights matter too. When the migration ends, remove temporary database users, FTP accounts and share links. Revoke access for outside teams as well. That way, doors you opened for the move don't stay open after it.

In other words, a redesign is also a good moment for a cleanup. Leaving behind test accounts and spam form entries makes the new system lighter.

Should you handle website data migration yourself?

It depends on data volume and platform change. If you move to a new theme on the same platform, the database stays in place and the risk is low. If the platform changes, for example from an off the shelf system to custom software, field mapping and password compatibility need expertise.

My advice: whoever designs the site, give data migration one named owner who signs off on the verification report. When responsibility floats between "the designer thought" and "the developer thought", the data gets lost right there.

If you do it yourself, at least don't skip the backup, the trial run and the count check. Those three steps would have prevented most of the losses I have seen. On redesign projects, I treat the data side as a core part of my web design service.

What should you monitor in the first 30 days?

The first month after launch is when hidden data issues surface. During that time, I track a few signals on a regular basis.

• Support requests that say "I can't log in".
• Form submissions compared with the pre launch average.
• The daily flow of conversion events in GA4.
• Crawl and indexing errors in Search Console.
• Empty or broken fields in order and invoice records.

A sudden drop in form entries usually points to a data or tag issue, not design. To read those signals, use the approach from my guide to reading marketing reports. Overall, the migration doesn't end on launch day. It ends when the numbers settle at the end of the first month.

For the broader framework, Google Search Central's site move guide is a solid starting point. If you get stuck on the data side, get in touch.