Can I Build a New Website While My Old Website Stays Live?
A replacement website can normally be designed and tested separately while the existing site continues serving customers.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
Yes. A new website can normally be designed, built and tested in a separate environment while the existing website remains live. Customers continue using the current site until the replacement has passed its checks and the domain is deliberately directed to it.
This approach reduces disruption, but it needs coordination. Content can change during the project, forms and integrations must be tested, and the final switch needs a clear plan.
How parallel website development works
The new site is built at a private development address, on a local machine or in a protected staging environment. It uses its own deployment and does not replace the public website during day-to-day work.
Reviewers access the new version through an agreed preview. Search engines should not treat that preview as the public site. Sensitive content and customer data should not be placed in an unsecured environment.
At launch, the production hosting or domain routing is changed so the public domain serves the new build. The old system is retained temporarily as a backup rather than cancelled immediately.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Keep the current site operational
Continue essential maintenance on the live site. Repair security issues, broken contact forms and inaccurate business information rather than waiting for the replacement. A rebuild does not make current customer risks disappear.
Limit optional structural work that will be discarded soon, but do not allow the site to become unsafe or misleading. Record every content or configuration change made after the migration copy was taken.
Assign one person to decide whether a live change must also be applied to the new site. This prevents opening hours, prices and service details from diverging.
Choose an appropriate development environment
A local environment can be fast and private, while a hosted preview makes stakeholder review easier. The right choice depends on the technology, team and integrations.
Protect previews from public discovery and unauthorised access. A noindex instruction can discourage indexing, but it is not access control. Use real authentication where confidentiality matters.
Avoid using the live customer database for routine tests. Use fictional, minimised information and ensure test emails, payments or bookings cannot reach real customers unexpectedly.
Preserve control of the domain
The domain does not need to move while the new site is built. Keep it in the business’s account, maintain renewal and document who can change DNS.
Do not point the public domain to staging for casual review. Review through a separate address. That keeps the existing website stable and avoids exposing unfinished pages.
The guide to what happens to a domain during a website replacement explains ownership, DNS and launch changes in detail.
Protect email and other DNS services
Website and email can use the same domain while being provided by different systems. Record the existing DNS zone, especially MX, SPF, DKIM and verification records.
A website launch should change only the records it requires. Replacing the whole DNS zone without preserving mail settings can interrupt email even though the website itself works.
Identify booking, payment, file-sharing and other services that also rely on DNS. Give each one an owner and a launch check.
Plan content migration early
Inventory pages, articles, downloads and important media on the old site. Decide what should be kept, improved, merged or removed. Do not leave this work until the layout is finished.
Draft real content in the new structure. Placeholder text conceals whether headings, cards and calls to action can handle the final words. Verify claims and permissions as part of migration.
The article on reusing existing content on a new website explains how to preserve value without carrying every old problem forward.
Control changes during the project
Long projects need a content synchronisation plan. Choose a date when routine changes will be limited, or maintain a log that editors can replay on the new site.
A complete freeze may be unrealistic for active businesses. Define exceptions for critical updates and give them a named route. Compare both versions before launch.
Forms, products, news and team pages deserve particular attention because they can change frequently. The final review should use current business information, not the initial migration copy.
Keep URLs stable where possible
A new design does not require new addresses. Preserve useful URLs when the subject and purpose remain the same. Stable routes reduce redirect work and protect bookmarks and links.
For every changed or removed URL, choose the closest relevant destination and plan a permanent redirect. Do not direct all old pages to the homepage.
Maintain a spreadsheet or structured map from each old URL to its final route. Test it against the built website before launch.
Review the new site without confusing customers
Use the preview for structured reviews rather than sharing it publicly. Give reviewers tasks and deadlines, and distinguish content approval from visual preference.
Check pages at phone, tablet and desktop sizes. Test navigation, forms, keyboard interaction, zoom and error states. Reviewers should use realistic content and journeys.
Do not collect real enquiries through the preview unless the system is explicitly prepared for them. A form that appears functional may send data to a test mailbox.
Test integrations safely
List every external system: analytics, consent, payments, bookings, maps, chat, email marketing and customer management. Decide how each behaves in development and production.
Use provider test modes where available. Confirm that secrets and API keys are not exposed in public code. Verify webhook destinations and notification recipients.
At launch, repeat the test with production settings. A working staging configuration does not prove the live credentials or allowed domain settings are correct.
Prepare search settings
The staging site should not compete with the current public site. Restrict access and use appropriate indexing controls. Make sure those controls are not copied accidentally to production.
Set canonical URLs for the live domain and prepare the final XML sitemap. Review metadata and structured data with the real page routes.
The website replacement guide covers the complete migration, including redirects and post-launch monitoring.
Decide when the new site is ready
Define acceptance checks for content, functionality, accessibility, performance, security, redirects, metadata and ownership.
Confirm that forms reach the business and show customers an accurate response. Check that critical pages have approved copy and working images. Resolve serious defects before cosmetic preferences.
Keep a launch blocker list with owners and decisions. Do not let a fixed announcement date force an unsafe release.
Choose a sensible launch window
Launch when the technical and business contacts are available. Avoid an unnecessary Friday evening or peak trading period. Allow time for immediate checks and correction.
Back up the existing site and record its configuration. Prepare a rollback route and decide what failure would trigger it. Confirm access before the launch begins.
If DNS changes are required, plan them in advance. Lowering time-to-live may help propagation, but only when it is done correctly and early enough.
Switch the website deliberately
Deploy the production build and redirects together. Point the domain or hosting route to the new system, preserve HTTPS and ensure the preferred domain works consistently.
Test from a network and browser that did not participate in development. Open major pages, old URLs and contact routes. Check server responses as well as visible appearance.
Do not cancel the old hosting during the switch. Keep it available for rollback and archival checks until the new service is proven.
Monitor the period after launch
Watch errors, form delivery, analytics, Search Console and customer feedback. Check that search engines can access intended pages and that the sitemap lists the final URLs.
Maintain redirects for the long term where old addresses have continuing value. Review unexpected not-found requests and add redirects only when a relevant destination exists.
Compare search and enquiry data over suitable periods. Normal variation does not automatically indicate a migration problem, but sudden widespread loss deserves investigation.
When downtime may still occur
Most brochure sites can switch with little or no noticeable interruption. Complex platforms may need a short maintenance window to synchronise orders, accounts or changing databases.
Plan that window, explain it to affected customers and prevent writes to systems that are being copied. Test the migration process before the real event.
Do not promise zero downtime without understanding the architecture and dependencies. A short controlled pause can be safer than losing transactions.
Common mistakes to avoid
Do not build over the live site, expose an unfinished staging site or forget changes made after the first content export. Do not cancel old hosting before DNS, redirects and forms have been verified.
Avoid launch-day domain transfers unless they are genuinely required. Moving ownership and changing the website at the same time creates another failure point.
Do not assume email follows the website automatically. Preserve its records and test it independently.
Frequently asked questions
Will customers see the unfinished website?
Not when the development environment is kept separate and protected. The public domain continues to serve the existing site until launch.
Can the same domain be used for both sites?
The public domain serves one production destination at a time. The new site can use a separate preview address during development and take over at launch.
Do I need to stop updating the old website?
Not entirely. Keep critical information and security current, then log changes so they can be reflected in the replacement.
Will the website be offline during launch?
Many brochure sites can switch with little visible downtime. Complex data migrations may need a planned maintenance window.
When can the old hosting be cancelled?
After the new site, redirects, email, forms, backups and rollback arrangements have been verified for an agreed period.
Keep continuity while improving the site
Building separately lets the business continue serving customers while the replacement is reviewed properly. Protect the current service, control content changes and make the final switch only when the evidence supports it.
Afterworks plans this continuity into website rebuilds, including staging, migration, testing and launch ownership.
