Moving the Data Is the Part of a Rebuild Nobody Quotes For

A business rang us a fortnight before their new website was due to go live. It wasn’t our build. The designs had been signed off months earlier, the pages were finished, and the thing was in its last round of checks when someone from their customer service team asked a question nobody else had thought to ask.

“The customers can still log in with their current passwords, can’t they?”

That question needs answering in the first week of almost any rebuild, whether it’s about passwords, order history, or the three hundred blog posts from 2014 that still bring in a surprising share of the traffic. When it surfaces a fortnight before launch instead, it’s usually because the quote the business accepted described the new site in detail and said very little about how the old one would get into it.

Why does migration get left out of the quote?

Because it’s invisible when the project is being scoped. A brief for a new website describes the new site, much as a builder’s quote describes the house. It says nothing about the move: the packing, the twenty years in the garage, the wardrobe that won’t fit up the new stairs. When someone builds a house, everybody understands the removal is a separate job with a cost of its own. On a website rebuild it tends to be assumed into the price.

The trouble is that the old data is almost never in the shape the new system expects. Years of use leave marks. Phone numbers end up stored in five different formats, and the same customer gets entered three times with slightly different spellings. There’s usually a field labelled “fax” that the sales team has been using for the account manager’s initials since 2017. Product descriptions pasted in from Word carry hidden formatting that breaks the new layout, and pages built with a page-builder plugin have their content wrapped in codes that mean nothing to any other system.

Nobody is to blame for any of this, since it’s what data looks like after years of real use. But turning it into clean records the new system can use is real work. How much work depends on how messy the old data is rather than on how big the new site is. A small site with a decade of tangled history can take longer to migrate than a large one that was well kept.

Why can’t customer passwords just be copied across?

This is the part that surprises people most, so it’s worth taking slowly.

A properly built system never stores your customers’ passwords. It stores a hash of each one: the result of running the password through a one-way mathematical process. When a customer logs in, the system hashes what they typed and checks it against the stored hash. If the two match, the password was right.

The useful comparison is a fingerprint. You can check a finger against a fingerprint on file, but you can’t rebuild the finger from the print. A hash works the same way. It can confirm a password but can’t be turned back into one. The design is deliberate, because it’s what protects customers if a database is ever stolen.

It also means the passwords can’t be handed over. The old developer can’t do it, the hosting company can’t, and neither can we, because the original passwords aren’t stored anywhere to be moved. So a rebuild that includes customer logins needs a deliberate strategy. In practice there are three realistic ones.

Bring the old hashes across and upgrade them as people log in. The new system is taught to check passwords the way the old one did. When a customer logs in successfully, it has the real password in hand for that moment, so it re-hashes it with its own modern method and throws the old hash away. Customers notice nothing. The catch is that it depends on knowing exactly how the old system hashed passwords, including any secret value it mixed in, which may be sitting in a configuration file on a server someone is about to switch off. Get that before anything is decommissioned.

If the old method was weak (and on older systems it sometimes is), the old hashes shouldn’t sit in the new database as they are. They can be wrapped straight away, by running a strong modern hash over the weak one, so there’s never a period where weak hashes are waiting around to be stolen.

Import the accounts and ask everyone to set a new password. When the old hashing can’t be recovered or can’t be trusted, this is the clean and secure choice. The cost lands on your customers and your support team. Every customer has to act, and a fair number won’t read the email at all. Of those who do, a few will find it in their spam folder, and others will reasonably wonder whether a message asking them to reset their password is a phishing attempt. If you go this way, plan the communication as carefully as the code: warn people before launch, explain it on the login page, and brief whoever answers the phones.

Keep the old hashing method permanently. It’s the simplest option, and acceptable only if the old method is already strong. If it isn’t, this carries an old weakness into a new system, which is a poor trade for saving a few days of work.

Most rebuilds we see end up using the first approach with a deadline attached. Accounts upgrade as people log in, and anyone who hasn’t logged in within, say, a year is moved to a password reset. Dormant accounts shouldn’t carry old hashes forever.

What happens to your search rankings when the URLs change?

Every page on your current site has an address, and those addresses have spread further than most people realise. Google has them indexed. Other websites link to them, and those links are a large part of why Google trusts your site in the first place. Customers have them bookmarked, old newsletters point to them, a PDF brochure someone still hands out has a few printed in it, and occasionally one is on a QR code on the side of a van.

A rebuild usually changes the site’s structure, which changes those addresses. Without a plan, every one of them becomes a “page not found”, and the ranking value that page had built up over years goes with it. Sites can lose a large share of their search traffic this way in the weeks after launch, which a little planning prevents entirely.

The fix is a redirect map: a list of every old address and the new page it should send people to, set up as permanent (301) redirects so search engines transfer the page’s standing to its replacement. It’s the website equivalent of mail redirection with Australia Post, except it’s set up address by address and it should never lapse.

Build the list of old addresses from several sources, since no single one has everything: a crawl of the current site, the analytics for the past year or two, Google Search Console, and the site’s own records of content. Map each address to the most relevant new page, one to one wherever possible. Resist the temptation to send everything that doesn’t have an obvious match to the homepage. Search engines tend to treat a flood of redirects to the homepage much like missing pages, and visitors find it confusing. Where a page has no successor at all, let it return a proper “gone” response rather than pretending.

Carry over the page titles and descriptions that were earning their keep, and don’t forget images and downloadable files, which have addresses of their own. After launch, watch Search Console for errors for several weeks and fix what turns up. Keep the redirects in place for years. They cost almost nothing to maintain.

How should a migration be planned?

It should be planned as its own piece of work with its own line in the budget, rather than a task someone does in launch week. The migrations that go well tend to follow a similar sequence.

Take an inventory. Everything that exists: pages, posts, products, customers, orders, form submissions, files, and anything else the business relies on. Include the things that live outside the website but feed into it.

Decide what not to move. This is the website equivalent of throwing things out while you pack. Old campaign pages, discontinued products, test accounts and spam form submissions don’t need migrating. Keep an archive of the old data somewhere safe, then leave the clutter behind.

Map and clean. Work out where every old field goes in the new system, and settle what happens to the awkward ones. This is where the fax field gets its answer, which needs someone who knows the business rather than only the developer.

Rehearse. Run the migration into a test copy of the new site, more than once. Count the records on both sides. Have the people who know the data check a sample by eye, because they’ll spot in a minute an error that a script would happily pass.

Plan the cutover. Decide when content editing on the old site stops, how orders or enquiries that arrive during the switch are caught, and what the steps are to go back if something goes wrong on the night.

When is a migration simple?

Sometimes it genuinely is. A twenty-page brochure site with no customer accounts, no shop and no history worth keeping can often be moved by a person copying content across by hand in a day or two, which is cheaper than writing and testing a script to do it. The redirect map for a site that size takes an hour.

The honest way to know which kind you have is to look at the data before the quote is written. That’s one of the reasons we ask to see the existing site’s back end during scoping, as well as its front end. What’s behind the pages decides how much work it is to move them.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He has met more than one “fax” field that turned out to hold something important. Reach out to Simon to talk through what’s involved in moving your data, logins and rankings to a new site.