A relaunch often begins with the desire for a new appearance. Shortly before the start, it becomes apparent that old downloads are missing, important URLs have no equivalent and no one knows who releases the new service descriptions. These problems are rarely purely design issues. They arise when a website change is planned without a complete inventory.

A successful relaunch combines goals, content, design and operation. This requires a process that makes decisions visible early on and keeps the transition verifiable. The following steps describe a practical approach for company websites. The scope and participants vary, but the fundamental questions remain similar.

Don't just look at the inventory, but record it

It starts with a list of existing pages, files, forms and external integrations. This also includes content that is hardly accessible via navigation. Old landing pages, linked PDF documents and previous campaigns can still be accessed. A backup of the source code alone does not automatically capture all editorial content or configurations.

For each important URL, it should be noted what purpose it serves and whether it will be preserved, merged, or removed. Existing access data can provide information, but must be interpreted in the respective context. A rarely accessed technical guide can be business critical for a few customers. The inventory decision must therefore not depend exclusively on a ranking list.

Translate goals into verifiable tasks

“Becoming more modern” describes a direction, but not an acceptance criterion. What is more tangible, for example, is that interested parties can find a suitable service and send a qualified inquiry. The editorial team also needs goals: What content should be able to be updated without developer help? Who reviews and publishes them?

These tasks help with prioritization. A new animation can be interesting, while an understandable product comparison can directly support a decision. Benefits, effort and responsibility should be identifiable for each major function. A limited initial scope with clear quality is often easier to plan than a start date that is constantly postponed due to additional requests.

Develop content before final design

Placeholder texts hide problems. A compact template heading will fit on a card, but an actual service description may not. The number of downloads, contact persons or product features also influence the layout. Therefore, central content should be available early on in a reliable version.

The migration requires a mapping between old and new content fields. The target system must be able to sensibly accommodate formatted text, image descriptions, categories and metadata. Automated takeover requires random samples and quantity checks. For manually revised pages, it should be documented which version was technically approved. Otherwise, an outdated text version will easily be adopted shortly before the start.

Check information architecture and design together

Navigation, headings and links determine how people understand the offer. A sitemap can be checked using typical search tasks before all pages are designed. An uninvolved person should be able to say under which menu item they expect certain information. In this way, misleading terms are caught early on.

Recurring components are then tested with real content. This includes cards, forms, detail pages and error messages. Responsive display and keyboard operation are part of this phase. A design that is only approved as a screen image does not provide an answer to how an opened menu or a form error actually behaves.

Treat URLs and search engines carefully

When addresses change, relevant old URLs need appropriate redirection. A blanket redirection of all pages to the homepage is often not a sensible equivalent. The landing page should replace the original content as appropriately as possible. If there is no substitute, the appropriate status must be consciously chosen.

Google Search Central recommends systematic preparation and monitoring for moves involving URL changes. In practical terms, this means a checked assignment list, consistent internal links and updated sitemaps. Test systems should not be indexed unintentionally. Conversely, when starting, a previously set lock must not accidentally remain on the production website. Indexing control belongs on the go-live checklist.

Fully test forms and external services

A form is only checked when the entire process works: entry, validation, storage, confirmation and, if necessary, notification. A green success message says nothing about the actual delivery of an email. Attachments, mandatory fields and rules for voluntary additional information should also be tested.

External maps, calendars and embedded media need their own inventory. What loads before activation? Which data flows where? Do the data protection information and technical implementation correspond? When relaunching, no old integration should be adopted unnoticed just because it was already present in the previous system. Access data and productive recipients must be carefully configured.

Technical clearance with return route

Before switching, a consistent backup including database, media and configuration is required. It must also be clear how recovery will take place. A return path is only useful if incoming requests or changes after the start are taken into account. Simply copying back an old database can result in the loss of new business transactions.

The release should therefore specify responsibilities and time windows. Who changes DNS or web server mapping? Who checks certificates, redirects and error logs? Which observation leads to termination? Even a small relaunch benefits from a written list that is processed during the start and not only put together in the event of a problem.

Don't change everything at the same time

If the domain, CMS, URL structure and hosting change at the same time, troubleshooting becomes more difficult. Sometimes a combined change is necessary. Then the individual changes should still be documented and checked separately. Where possible, preparatory steps may be brought forward. This reduces the number of unknown factors in the crucial time window.

After the start, the observation begins

Initial checks include core pages, forms, mobile navigation, redirects and media. Error logs and unusual call patterns are then observed. External links or search engines can continue to use old addresses for a long time. A missing forwarding can be added later if the monitoring makes such calls visible.

The editorial team should also provide feedback in this phase. Can content be maintained as planned? Are image crops and previews understandable? Small corrections after launch are normal, but must not bypass technical tracking. Changes are documented and re-examined according to their effect.

Test content migration on representative cases

A migration should not only be tested with a short standard page. Choose a long specialist article, a page with several images and a process with a download or form. Alternative texts, lists, special characters and internal references are also checked. A technically successful import can still lose important relationships or formatting.

When it comes to images, it is important to check whether files are actually available in the new system or continue to be loaded unnoticed from the old environment. Such connections can break after the old server is switched off. Relative links and previous subdirectories should also be examined. A path that works on the test system may not have the same meaning on the final domain.

For acceptance purposes, a migration log can record which content has been automatically adopted and which has been re-edited. Samples are confirmed by the technically responsible persons. If content continues to change during implementation, an agreed editorial deadline or a procedure for adopting the final differences is required.

Once started, the old environment is not hastily deleted as the only source of comparison. A protected, consistent backup enables later queries. It must not unintentionally create a second public website with outdated forms or access data. Storage, access and shutdown are consciously planned.

A useful starting list

  • Content, contact details and legal information are technically approved.
  • URLs, canonicals, redirects and indexing rules were checked.
  • Forms work including error cases and notification.
  • Images, downloads, navigation and keyboard operation have been tested.
  • Backup, recovery and responsibilities are clear.
  • Follow-up checks and care are mandatory.

GRITTMANN can accompany a relaunch from inventory and design to technical implementation. A sensible way to start is to look together at the existing content and the most important tasks of the website. This makes it clear early on what actually needs to be renewed and what has proven itself.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 11.06.2026.