The Step Nobody Talks About

When most people hand over a website migration project, they are thinking about the destination. New design. Better performance. Clean code. A site that finally reflects where the business is now rather than where it was three years ago.

Fair. That is the point of the exercise.

But there is a step that happens before any of that — before we write a line of code, before we touch the hosting environment, before we even look at your new sitemap — and it is one of the most quietly important things we do. We take a full, structured screenshot archive of your existing site. Every page. Every state. Every piece of content we can capture.

Then we document what we found, store it somewhere you can access forever, and only then do we start the actual work.

This post is about why that matters — not in a vague 'due diligence' sense, but in specific, concrete ways that have saved real projects from real problems. If you are planning a website migration, a redesign, or a platform move of any kind, this is worth reading before you start.

What 'Deleting' a Website Actually Means

The word 'delete' is a little theatrical. You rarely bin a website in one clean motion. What actually happens is messier: files get overwritten, databases get replaced, DNS records get pointed elsewhere, and the old environment quietly ceases to be the live one. Within days or weeks, the old hosting lapses, the backups age out, and the previous version of your site simply stops existing anywhere accessible.

From a practical standpoint, that is deletion. The content is gone. The structure is gone. If you did not capture it, you cannot get it back.

This happens faster than most people expect. A migration kicks off, the new site goes live, everyone is pleased, and attention immediately moves to the next thing. Nobody is thinking about the old site. Nobody is archiving it. It evaporates.

What Gets Lost When Nobody Is Looking

The obvious losses are the ones people notice immediately: a page that existed on the old site that does not have an equivalent on the new one, broken inbound links, a redirect that was never set up. Those surface quickly and they get fixed.

The less obvious losses take longer to bite. Historical copy that a copywriter spent weeks refining. Structured data that Google had indexed and was using to surface rich results. A terms and conditions page that contained specific wording your legal team had approved. A product description that a customer references in a complaint and you cannot verify because the version they saw no longer exists.

These are not theoretical edge cases. They are the kinds of things that come up — often months after the migration — and at that point, without an archive, you are working from memory.

The Real Reasons We Do This

There are four distinct reasons the pre-migration screenshot archive matters, and they operate at different layers of the project. Let me walk through each one honestly.

Reason One: Audit Trail and Legal Protection

Businesses accumulate regulatory obligations on their websites over time. Cookie policies. Privacy notices. Terms of service. Accessibility statements. Disclaimers on specific product pages. In many jurisdictions, you are required to be able to demonstrate what your website said at a given point in time — for consumer protection purposes, for GDPR compliance, for financial services regulation, for disputes.

If you cannot show what your site said before the migration, you cannot prove compliance. That is a real liability exposure, and it is entirely avoidable.

A timestamped screenshot archive is not a substitute for proper legal archiving in high-stakes regulated industries — but for most businesses, it provides exactly the kind of contemporaneous record you would need to resolve a dispute or demonstrate good faith.

Reason Two: SEO Recovery and Redirect Mapping

This is the one technical leads tend to understand immediately. Your old site has URL equity. Google has indexed those pages, assigned them authority, and is using them to rank your content. When you migrate, every URL that changes without a proper redirect is a vote that disappears.

The problem is that most people do not have a complete, accurate list of every URL their old site contained. The sitemap is usually incomplete. The CMS export is often messy. Developer-generated paths, tag pages, dynamically created product URLs, paginated archive pages — these are easy to miss.

A full crawl and screenshot archive gives us the authoritative list. Every URL. Every title. Every meta description. Every piece of structured content. That becomes the source document for redirect mapping — which, as we cover in detail in our walkthrough of the full migration process, is one of the most technically consequential parts of any website move.

Without that source document, redirect mapping is guesswork. With it, it is engineering.

Reason Three: Content Recovery and Reference

Clients often assume they have all their own content. In practice, they rarely do — not all of it, not in a clean and usable form.

The content on a website has usually been written and edited iteratively over years. Some of it lives in the CMS. Some of it was written directly into page builders and exists nowhere else. Some of it was added by a previous agency and the client never had access to the backend. Some of it is in a CMS that exports in a format that is technically complete but practically useless.

When we screenshot the old site — properly, with structure, not just a single image per page — we capture the rendered content exactly as a user would see it. That becomes the reference document for the content migration phase. If anything gets missed, misformatted, or accidentally truncated during the new build, we can compare against the archive and catch it.

This sounds like a minor quality assurance step. It is not. On complex sites with hundreds of pages, it is the difference between a clean handover and a six-week snag list.

Reason Four: Client Confidence and Institutional Memory

This one is harder to quantify but genuinely important. Website migrations create anxiety — especially for founders and business owners who have been close to their site for years. There is a real fear that something will get lost, that the new thing will not have everything the old thing had, that the work of years will somehow evaporate.

Showing a client a complete visual archive of their old site — organised by section, with every page captured — addresses that anxiety directly. They can see that nothing has been thrown away carelessly. They have a record of what existed. If they want to reference something from the old site a year from now, they can.

It also preserves institutional memory in a way that database exports do not. A screenshot archive is human-readable. Anyone on the team — technical or not — can look at it and understand what the old site contained. That matters when businesses change personnel, when new team members join after the migration, when questions arise about historical decisions.

What a Proper Archive Actually Looks Like

A screenshot is not just a picture of a webpage. Done properly, a pre-migration archive is a structured document set with several components working together. Here is what we actually capture and how we organise it.

Full-Page Screenshots at Multiple Breakpoints

Desktop, tablet, and mobile. Not just the viewport — the entire scrollable page length. This matters because responsive layouts can differ significantly between breakpoints, and content that is visible on desktop is sometimes hidden, collapsed, or rendered differently on mobile. You need the full picture at every size.

Crawl Data Export

A structured export from a site crawler — we use a combination of tools depending on the project — that captures every URL, response code, title tag, meta description, H1, canonical tag, and inbound internal link. This is the spine of the redirect map and the SEO baseline document.

Metadata and Structured Data Snapshot

Schema markup, Open Graph tags, structured data blocks — all of this needs to be captured and carried over (or consciously improved upon) in the new site. If it existed on the old site and is not replicated on the new one, you will lose search features you may not even have known you had.

Form Captures and Interactive States

Contact forms, quote request forms, multi-step flows — these need to be captured in their various states, not just the initial rendered view. What error messages existed? What confirmation messages did users see? What validation logic was in place? This detail is easy to miss and often needs to be recreated on the new platform.

Timestamp and Version Documentation

Every capture is timestamped. The archive is dated. If the capture happened over multiple sessions (which it often does on larger sites), each session is logged. This is what makes the archive useful as a legal or compliance reference — provenance matters.

A Practical Framework: The Pre-Migration Archive Checklist

If you are managing a migration yourself, or working with a team that needs a structured approach to this, here is the framework we work from at Daybrain Digital. Adapt it to your context.

Phase 1 — Discovery (Before Any Work Starts)

Phase 2 — Visual Capture

Phase 3 — Metadata and Technical Capture

Phase 4 — Content Documentation

Phase 5 — Archiving and Handover

This is not a quick process on a large site. On a site with 500+ pages, this phase alone can take two to three days of careful work. That is not overhead — it is risk management.

A Worked Example: What Goes Wrong Without This Step

Let me give you a concrete scenario. This is a composite drawn from patterns we have seen — not a single client story, but a realistic representation of how this plays out.

A professional services firm — mid-sized, regulated industry — commissions a website redesign. The agency is competent. The new site looks significantly better. The migration goes live on schedule.

Three months later, a former client raises a complaint about services they received eighteen months prior. They reference the service description page on the website as it existed when they engaged — specifically, a paragraph about scope and exclusions. The firm's position is that the service was clearly scoped. The former client's position is that the wording was ambiguous.

Nobody archived the old site. The hosting had been cancelled. The agency had moved on and their backups had expired. The Wayback Machine had captured one version of the page, but it was from eight months before the relevant period, and the content had been updated in the intervening time.

The firm cannot produce the page as it existed at the time of the engagement. They cannot confirm or deny what the wording said. The dispute becomes significantly more complicated and expensive than it needed to be.

A timestamped visual archive of that page — taken before migration — would have resolved this in an afternoon.

This is not a technology problem. It is a process problem. And process problems are entirely preventable.

Why This Is Often Skipped

Honestly? Because it takes time, it is not visible to the client in the way that design work is, and it does not feel like it produces anything. An archive of your old site feels like a receipt for something you have already paid for. It is hard to assign obvious value to it until you need it.

Agencies skip it because clients do not ask for it. Clients do not ask for it because they do not know it is missing. And so the entire step gets quietly omitted from most migration projects, and nothing goes wrong — right up until it does.

There is also a subtle psychology at play. Everyone involved in a migration is excited about the new thing. The old site is the problem being solved. There is very little enthusiasm for carefully documenting and preserving the thing you are replacing. It feels like the opposite of progress.

It is not. It is due diligence. And due diligence is what separates projects that age well from projects that create problems two years after they shipped.

The SEO Dimension Deserves More Attention

We touched on redirects earlier, but the SEO implications of a poorly archived migration go deeper than redirect mapping.

Search engines build a model of your site over time. They understand your URL structure, your internal linking patterns, your content depth, your page authority distribution. When you migrate, you are asking Google to rebuild that model from scratch on the new site. If the new site does not accurately replicate the structure of the old one — or consciously and correctly improve upon it — you lose ground. Sometimes a lot of ground.

The archive is what lets you audit whether the new site has correctly accounted for everything the old one contained. Not just the top-level pages — the long tail. Blog posts from 2019. Product variations that were individually indexed. FAQ pages that were ranking for specific queries. These are easy to miss and often account for a meaningful portion of organic traffic.

If you are not sure whether your current site is performing as well as it should be — or whether a previous migration left things behind — the diagnostics we cover in our piece on websites as sales tools give you a practical starting framework. The SEO health of your site and its conversion performance are connected in ways that are not always obvious.

A well-archived migration also gives you a clean before-and-after comparison for performance. You can measure traffic, rankings, and conversion rates on the new site against documented baselines from the old one. Without the archive, you are comparing against memory — which is not a measurement methodology.

What Clients Should Ask Their Agency

If you are about to commission a website migration or redesign, here are the specific questions worth asking before any work starts. These are not trick questions — any competent team should have clear answers to all of them.

The answers to these questions tell you a great deal about how systematically a team approaches the parts of a migration that are not immediately visible.

At Daybrain Digital, the archive phase is a non-negotiable part of our migration process — not an optional add-on. If you want to understand the full sequence of how we approach a migration from initial diagnosis through to post-launch verification, we have documented it in detail in our migration process walkthrough.

A Note on Third-Party Archive Tools

Some teams rely on the Wayback Machine (archive.org) as their backup plan. It is better than nothing — but it is not reliable enough to depend on for anything important.

The Wayback Machine crawls on its own schedule, which may not coincide with your migration date. It captures what its crawlers find, which often misses dynamically generated content, content behind authentication, and content on pages that are not well-linked internally. It renders pages without their stylesheets in some cases. And you have no control over the timestamps — you cannot force a capture to happen the day before your go-live.

It is a useful supplementary reference. It is not an archive strategy.

Similarly, CMS export tools — whether WordPress XML exports, Contentful JSON exports, or platform-specific backup files — capture database content but not rendered output. They do not show you what the site actually looked like. They do not capture page builder content reliably. And they require technical skill to interrogate — they are not human-readable records.

The visual archive is the layer that makes everything else human-readable and independently verifiable. It is the thing a non-technical stakeholder, a legal team, or a new team member can look at and immediately understand.

Migrations That Touch Platform Changes

If your migration involves moving between platforms — say, from a website builder to a properly hosted custom build — the archiving step becomes even more critical. When you move between fundamentally different technical environments, the export tools available to you are often platform-specific and incomplete by design.

We have written about the practical differences between website builders and custom hosting in our comparison of Wix versus properly hosted sites. One of the underappreciated aspects of that transition is data portability — or the frequent lack of it. Platform-native content often does not travel cleanly. The visual archive fills that gap.

When you are changing both the platform and the design simultaneously — which is common in a full redesign — the archive becomes the only clean reference document that exists entirely outside both environments. It is neutral ground. It shows you what existed, independently of where it was hosted or how it was built.

What Happens to the Archive After Go-Live

This is worth addressing explicitly because most clients never ask and most agencies never explain it.

The archive should live somewhere permanent and accessible. Not in a project management tool that the agency controls and that you might lose access to if the relationship ends. Not in a temporary shared drive link. In a location you own — your own cloud storage, your own document management system — that you can access independently of any third party.

At minimum, you want the archive to be accessible for as long as your potential legal or regulatory exposure exists. For most businesses, that means a minimum of six years (the standard limitation period in many jurisdictions for contract disputes). For regulated industries, longer.

The archive should also be indexed. A folder of thousands of unlabelled screenshots is technically an archive but practically useless. You need a summary document that maps page names to file locations, notes the capture date, and flags any gaps in coverage. This is a thirty-minute task that makes the rest of the archive infinitely more useful.

The Broader Principle

Behind the specific practice of archiving old websites is a broader principle that applies to most serious technology work: the transition state deserves as much attention as the destination state.

Most project energy goes into what you are building. The architecture, the design, the features, the performance targets. Very little energy goes into the process of getting from where you are to where you want to be — and the things that need to be preserved or correctly decommissioned along the way.

This is where projects accumulate invisible debt. The old API that nobody properly deprecated. The user data that was never migrated cleanly. The historical content that got dropped somewhere in a platform move. The configuration that existed on the old server and was never documented. These are not dramatic failures — they are quiet omissions that create problems on a delay.

Archiving the old site before you delete it is a small, specific instance of taking the transition state seriously. It is not complex. It is not expensive relative to the cost of a migration project. But it requires someone to decide that it matters and to build it into the process as a requirement rather than an afterthought.

That decision is what separates migrations that age well from ones that leave you scrambling for something you cannot find.

The Takeaway

Before any migration work starts, the old site needs to be fully documented — not for nostalgia, not out of excessive caution, but because you are about to permanently destroy a version of your business that exists nowhere else. The content, the structure, the metadata, the legal record of what you said to your customers — all of it is about to become inaccessible.

A structured screenshot archive, combined with a crawl data export and proper metadata capture, prevents that loss. It takes time. It produces a deliverable that most people will never need to open. But the minority of cases where you do need it — a compliance question, a content dispute, an SEO investigation, a new team member trying to understand what came before — the archive is the only thing standing between you and an expensive exercise in guesswork.

If you are planning a migration and want to understand how we handle this from the first conversation through to post-launch, Daybrain Digital is the place to start. The archive is the first thing we do. It will also be the last thing you think about — until the day you are very glad it exists.