How a Website Redesign Actually Runs: Warning Signs, Scope Definition, and the Cutover Plan
“The site is looking a bit dated — should we redesign it?” That thought usually arrives as an instinct, but a redesign is a project that touches search rankings, business processes, and internal operations.
Redesigns rarely fail because the design was unattractive. They fail because the scope was never defined: halfway through, somebody discovers there are several hundred articles to move, form notifications to reconnect, a payment integration to reapply for, and a pile of legacy pages nobody remembered existed. This guide breaks a redesign into stages you can follow, so that you know the size of what you are signing up for before work begins.
When a redesign is actually warranted
The reason for a redesign should be expressible as a concrete loss, not as “we are tired of looking at it.” The signals that genuinely qualify tend to be these:
- The content no longer matches the business. The site still lists services from two years ago, while the work that actually pays the bills has no page at all.
- The mobile experience has fallen behind. Visitors have to zoom in to read, forms drop out halfway through, pages take too long to load.
- Content updates depend on the vendor. Changing a single line means sending an email and waiting; nobody internally has any autonomy.
- The architecture is blocking new requirements. You want member accounts, an integration with an internal system, or a second language, and the current platform cannot do it.
- Security has fallen behind. The system or the packages it relies on are no longer maintained and can no longer receive security updates. This one belongs in the must-handle category; for how to assess it, see Website Security Basics for Businesses.
Conversely, if the problem is only that the visual style feels dated, or that a few pages are laid out badly, that is localized optimization and does not require rebuilding the whole site. Escalating a small problem into a large project is one of the most common ways a budget gets consumed.
Define the goal and the scope before you talk about design
The first question a redesign should answer is not “what should it look like” but “once this is done, what specifically gets better?”
Write the goal as a sentence you can verify. For example: a prospect should be able to find the service description and submit an inquiry within three clicks; the marketing team should be able to publish an article without contacting the vendor; the quoting process should move from phone calls to an online form. The more specific the goal, the more grounded the later arguments about layout will be.
Then define the scope. In practice it helps to write three explicit lists:
| List | What goes in it | Why it matters |
|---|---|---|
| In scope | Pages, features, content to migrate, systems to connect | The basis for the quote and the schedule |
| Out of scope | Items explicitly excluded | Prevents endless late additions |
| Next phase | Valuable, but not required for launch | Gives ideas somewhere to go without crowding the current phase |
The third list is routinely skipped, and it is the most useful of the three — when somebody raises a new idea, you do not have to reject it, only file it under “next phase,” and the project stops expanding one suggestion at a time.
Writing those three lists clearly is, in effect, the skeleton of a requirements document. For the full method, see How to Write Software Requirements, which gives a structure a non-engineer can fill in.
Take inventory of the existing content and functionality
This is the dullest step and the one most likely to be skipped, and the cost of skipping it usually surfaces in the last week before launch.
A content inventory means listing every URL on the existing site and marking each one: keep, rewrite, merge, or delete. Record each page’s actual value alongside it — is anyone reading it, has it produced any inquiries, is it legally required to exist (a privacy policy, for instance).
A functionality inventory means listing everything the site currently does, including the parts nobody sees: who receives form submissions, which analytics tools are connected, whether scheduled notifications go out, whether any other system calls in to pull data. These invisible functions are the ones most likely to vanish after a redesign, and the business side is usually the one to notice.
An asset inventory covers the licensing status of images, video, fonts, and stock libraries. Assets used on the old site cannot always be carried over, and font and stock library license scope deserves particular attention.
The output of the inventory is a spreadsheet, and that spreadsheet doubles as the basis for content migration and for acceptance later.
How the design and development phases should run
A healthy redesign project produces something you can confirm at the end of every stage, rather than revealing the finished article at the very end.
Information architecture comes first: how the navigation divides, which content belongs together, what the URLs look like. This step determines whether users can find anything, and it determines later search performance too.
Wireframes and visual design follow, confirming layout structure and interaction flow before addressing visual style. Moving into development only after the designs are signed off avoids a great deal of rework.
Development and iteration works best on a fixed rhythm that produces something you can operate. NETVANA works in two-week sprints and delivers a working demo at the end of each one, so that you experience the thing in a real environment rather than imagining it from a picture; for the full breakdown of phases, see the software development process.
Testing and acceptance covers more than appearance: cross-device compatibility, form flows, admin operations, and performance. For how to set performance acceptance criteria, see the Website Speed Optimization guide.
If the redesign also replaces the admin system, that is a separate decision in its own right; the trade-offs between the four routes are set out in How to Choose a CMS.
Content migration: the most underestimated stretch
Content migration gets treated as copy and paste. It actually contains four distinct jobs:
- Moving. Relocate the content you are keeping into the new structure and confirm that formatting, images, and attachments all survived.
- Rewriting. Use the redesign to clear out content that is outdated, duplicated, or inconsistent in tone.
- Remapping. Build an entry-by-entry correspondence between old URLs and new ones.
- Checking links. Internal cross-references and inbound links from external partners both need to be confirmed unbroken.
Items three and four directly determine search performance after the redesign. The detail is not repeated here — for how to build the URL mapping table, how to configure redirects, and what to monitor after launch, see the Website Redesign SEO Checklist. For the technical groundwork the new site should get right during development, see the Technical SEO Checklist.
On sequencing: move the structure and the important pages first, then the long tail. If the content volume is large, run migration in parallel with development rather than waiting for the site to be finished before you start.
Cutover and rollback planning
The moment of the switch is where the project’s risk is most concentrated. Prepare in this order:
Before the switch
- A complete backup of the old site (code, database, uploaded files), with the restore actually tested
- A record of the original domain and hosting settings, including anything mail-related
- A final check of the new site in the production environment, and confirmation that the staging environment cannot be indexed
- A low-traffic window, clear of campaigns and promotional periods
At the moment of the switch
- Confirm item by item: homepage, main service pages, form submission, admin login, payments if any, and whether the analytics tools are reporting data
After the switch
- Check error logs and form submissions daily for the first few days
- Confirm that search engines are beginning to crawl the new URLs
- Collect real usage feedback from internal colleagues
The rollback plan should be written before the switch, not improvised after something breaks. It needs to state who decides to roll back, on what conditions, the specific steps involved, and what happens to any new data created in the meantime. For a complete item-by-item pre-launch check, pair this with the Pre-Launch Website Checklist.
The four most common redesign mistakes
One: treating the redesign as a pure design job. A designer is hired, nobody owns content migration or system reconnection, and the launch leaves a trail of dead ends.
Two: no named decision-maker. Every review round brings new opinions, the design never settles, and the schedule is consumed by successive revisions.
Three: leaving content until last. Development finishes, and launch is blocked because the copy and the product photography never arrived.
Four: treating launch as the end. The period right after a redesign is an observation window that needs somebody watching the data and fixing problems. Say so during the quoting and contract stage; for the relevant cost structure, see How Website Costs Are Calculated.
Whether a redesign goes well is mostly decided before work starts: how specific the goal is, whether the scope was defined, how thorough the inventory was. With those in place, design and development turn out to be the comparatively simple part.
If you have a site due for a redesign and you are still deciding between localized improvement and a full rebuild, talk to NETVANA about your redesign plan. We clarify the current situation and the scope before discussing approach. Software services are quoted individually rather than sold as fixed packages; for what each service includes and delivers, see the software services overview.
Further reading: the biggest fear after a redesign is losing traffic, and the full migration procedure is in the Website Redesign SEO Checklist; to write the requirements yourself, see How to Write Software Requirements; to pick the admin system, see How to Choose a CMS; if the redesign includes an English version, start with the Multilingual Website Development Guide; and for why projects slip, see Why Software Projects Run Late. The cutover planning from a redesign works the same way for a system migration, see Data Migration When Replacing a System.
