Photo by Igor Miske on Unsplash
Ask anyone who has run a big site migration what went wrong and you will get the same answer in different words. The build was fine. Everything around the build was not.
Plenty of organisations are in the middle of one right now, often because they were pushed. Drupal 7 reached end of life on 5 January 2025, so a lot of sites that were ticking along quite happily suddenly had a deadline attached to them. Others are replatforming because the old system genuinely cannot do what the organisation needs any more.
Either way, the quote you get covers design, development and launch. Those are the predictable parts. What follows is the rest of it, in roughly the order it ambushes people.
Somebody has to decide what happens to every page you already have. That sounds obvious written down. It never gets estimated properly.
Run a crawl of the current site before you do anything else, and be prepared for the number to be wrong. A university department site that everyone describes as "about 300 pages" routinely turns up 2,000 URLs, of which maybe 600 have had a visitor in the last year. The rest are old news items, event pages from 2019, orphaned PDFs and three generations of staff directory.
You then need a decision against each one. Migrate as is, rewrite, merge into something else, or bin it. That work needs people who know the subject matter, which means the academics or the programme managers, not the web team. They have day jobs. This is why migrations slip.
One thing that helps: pull traffic data into the inventory before anyone starts deciding. It is much easier to get a department head to agree to delete a page when the sheet says four visits in twelve months than when you are asking them to judge it on merit. Merit is subjective. Four visits is not.
My honest advice is to do the deletion pass first and enjoy it. Cutting 40% of a site before migration is cheaper than migrating it and cutting it later, and nobody has ever complained about a 2019 event page disappearing.
If your URLs change, and in a replatform they usually do, every old address needs to point somewhere sensible.
Google’s own guidance on moving a site with URL changes is worth reading properly rather than skimming, because the failure modes are specific. Dumping hundreds of old URLs onto the new homepage is the classic one, and it gets treated as a soft 404 rather than a redirect. Pages you are deliberately not carrying over should return a 404 or 410, not a redirect to something vaguely related.
Search Console will complain about your old sitemap showing redirecting URLs after the move. That is expected and you can leave it alone. The mistake is reacting to the warning by pulling the old sitemap or switching redirects off early.
Keep the redirects in place far longer than feels necessary. Months, not weeks. And check them after launch rather than assuming the mapping worked, because a spreadsheet with 1,800 rows in it always has mistakes.
A migration of any size needs skills you do not have on staff full time. Someone who has done this exact upgrade path before. A front-end developer for the theme work. Probably an accessibility reviewer.
Most organisations solve it with a mix: the agency handles the platform, one or two specialists come in for the duration, and internal staff do content. That mix is sensible. What gets handled badly is the paperwork around the specialists.
A nine-month engagement with someone working full time on your project, using your systems, attending your standups, starts to look a lot like employment rather than a supplier relationship, and the country they live in gets to decide which it is. Hiring someone in Canada for that kind of stint means Canadian rules on notice, payroll deductions and statutory entitlements apply, whether you engage them directly, through a provider holding a local entity, or on an invoice basis that may not survive scrutiny.
There is also the intellectual property point, which catches people more often than you would expect. Code and design work produced by an employee usually belongs to the employer by default. Work produced by a contractor often does not, unless there is a written assignment. Get that signed before the first commit, not during a disagreement about the final invoice.
Here is the pattern I have watched several times now. The site launches, it looks great, everyone is pleased. Six weeks later it looks noticeably worse than it did at launch.
Nothing broke. Your editors just started publishing.
They learned the old CMS over years. The new one has different components, different rules about headings, a new media library, and probably a proper approval workflow where before they clicked publish. Nobody enjoys being slower at their job than they were last month, so people take shortcuts. They paste from Word. They use a heading because it looks the right size. They upload a 4MB photograph because cropping it is a faff.
A two-hour training session before launch does not fix this, partly because half the people who need it will be on leave, and partly because nobody retains a two-hour session about software they have not used yet.
What works better is breaking it up. Training management software lets you split the material into short courses by role, so an editor gets the four things they need and an approver gets a different set, then assign a refresher when the component library changes. It also means you can see who has actually been through it, which matters when a page goes up with no alt text and you are trying to work out whether that is a training gap or a person ignoring the rules.
Screen recordings on their own age badly, which is the other reason the one-session approach fails. Someone changes a component in month three and every video showing the old version is now teaching people the wrong thing. Nobody goes back and checks.
Universities tend to find this easier than corporates, incidentally, because running courses is already what they do. Applying the same approach to your own staff is not a new capability, just an unfamiliar use of an existing one.
Four things, and none of them are technical.
A content decision owner by name for each section of the old site, with a deadline that sits well before development finishes. A redirect map treated as a deliverable with someone accountable for testing it, rather than a task that gets squeezed in launch week. Written IP assignment for everyone touching the project who is not on your payroll. And a training plan that exists as material, not as a calendar invite.
None of that appears on a typical migration quote, and all of it determines whether the thing you launch is still good in a year.
Discover our other works at the following sites:
Danetsoft is a global web agency headquartered in Indonesia, specializing in web development, managed hosting, and web publishing platform.
[email protected]
Magelang, Central Java © 2026 Danetsoft. Powered by HTMLy
