A plain-language guide to how your site goes live

When your new website is ready to go live, one of the most important steps is updating your domain's IP address so that visitors are routed to the new site. This article explains what that means, why it matters, and what you can expect during and after the switch.

What Is an IP Address and Why Does It Matter?

Every website lives on a server somewhere on the internet. Your domain name (like www.yoursite.com) is a human-friendly label that points to a specific server. Under the hood, that pointer is an IP address—a numeric address like 192.0.2.10—that tells browsers where to go when someone types your domain.

When we build your new site, it lives in a staging environment on the same managed hosting platform as your live site. Your existing live site continues running undisturbed throughout the build and testing phase. Going live means moving the new site’s files and database into your live hosting environment—but there are a number of steps that must happen in the right order, and some disruption to your site during the process is unavoidable. This article explains what to expect.

How We Approach Your Go-Live

We offer two methods for launching your new site. Which one we use depends on your timeline, your risk tolerance, and how confident you are that the new site is ready to replace the current one. We’ll discuss both options with you before we begin.

Method A: Standard Migration (Same Hosting Account)

This is our standard approach for most site launches. Because your staging and live environments share the same hosting account and the same IP address, there is no DNS change or IP update involved. We migrate the new site on top of your existing live environment. Your domain, your SSL certificate, and your IP address all stay exactly the same throughout—your visitors simply start seeing the new site once the migration is complete.

Here’s what happens, in order:

1. We take a full backup of both your live site and your staging site before we touch anything.
2. We create a fresh database on your live hosting account. This sits alongside your existing live database without overwriting it, which preserves a fallback option in case anything goes wrong during the migration.
3. We use a professional migration tool to copy the staging site’s files on top of your live environment and connect them to the new database. As described in the note below, this overwrites matching files and adds new ones, but does not delete files that exist on the live site and are absent from staging.
4. We fix any URL or hardcoded path issues directly on the live environment after the migration. We do this on the live site—not on staging beforehand—so that staging remains a pristine, unmodified reference copy in case we need to compare the two or revert. We also adjust redirect rules if needed to ensure all URLs resolve correctly.
5. We install and configure security, caching, monitoring, and reporting tools. During this phase your site remains live, but visitors may see a brief maintenance notice, experience caching inconsistencies, or notice visual differences if they visit before caching has fully settled. This is normal and typically resolves within a short time.

A Note for Your Web Developer: File References and URL Links

Some developers work efficiently by referencing files that already exist on the live site while building in staging—for example, reusing existing images or uploads rather than uploading duplicate copies. When those files live in their own dedicated folder or in a location outside the standard WordPress directories, this generally works fine because those files will survive the migration as described above.

However, problems arise when the staging site references files or folders that will not exist after go-live—this is especially common in Method B, where the new site is moved to a completely separate hosting account and the old live site is no longer accessible at the same location. Images or assets that were “borrowed” from the live site will show as broken after the switch.

Our strong recommendation to your developer:

• Treat the staging site as if it is already the new live site. All images, folders, and content should exist inside the staging area itself—not borrowed or “hotlinked” from the current live site.
• Use relative links rather than absolute links wherever possible. An absolute link hard-codes a specific domain (e.g., https://staging.example.com/image.jpg) and will break immediately if the domain changes. A relative link (e.g., /image.jpg) works correctly regardless of which domain the site is currently served from, which saves significant time during and after migration.

Correcting URL references between staging and production is consistently one of the most time-consuming and technically risky parts of any migration. Following these practices upfront significantly reduces that risk and keeps your go-live on schedule.

Method B: Switchover with Easy Rollback (Temporary Second Account)

This method is designed for situations where you or your team want the confidence of being able to instantly revert if something unexpected comes up after go-live. It requires temporarily adding a second hosting account (typically for one to two months) at the same monthly rate as your current plan.

Here’s how it works:

1. Your new site is fully migrated to the production environment of the second hosting account.
2. We configure URLs, database settings, and everything else needed so the site functions correctly. We test it thoroughly using the temporary address before any DNS changes are made. SSL cannot be issued yet—that happens after DNS is pointed over.
3. We register your real domain name with the second hosting account on the day of the release. As with Method A, this does not affect your live site yet—it simply prepares the new server to accept your domain once DNS is pointed over.
4. When you give us the go-ahead, you (or we, with your permission) update the IP address on your domain to point to the second hosting account. This triggers the same cutover window and expected downtime described in Method A.
5. Your original live site remains completely untouched on the first account.
6. We install supporting plugins on the new live environment.

The key advantage: if anything goes wrong after go-live, reverting is as simple as changing the IP address back to the original server. The old site is still there, unchanged, ready to go.

Purchasing a Second Hosting Account for Method B

If you choose Method B, you will need to purchase a second hosting account for a month or two while the migration is underway. This section explains what that involves and what to expect in terms of cost and process.

What You’re Purchasing

The second account is a full hosting account at the same plan level as your primary account. If you are on our INVEST plan, the second account is also provisioned at the INVEST plan level. You will be billed at your normal monthly rate for the duration you hold both accounts, and we will cancel the second account once the migration is confirmed complete and you have given us the all-clear.

Migration Fees

In addition to the second account’s monthly hosting cost, Method B involves a separate migration fee. This covers the labor required to move your current staging site to the production area of the new account, configure the environment, correct all URLs, test the result, and coordinate the DNS cutover. We will provide you with a quote for this work before any migration begins so there are no surprises.

How the Second Account Works During Migration

We migrate your staging site to the production environment of the second hosting account and configure it as if it were your live site. Your current live site on your original account is not touched at any point during this process.

Once you give us the go-ahead, we register (alias) your domain with the second account and you change the IP address to point to it. At that point, the cutover window begins (see below). Your original account still has the old live site intact and sitting at its own IP address—reverting is as simple as pointing the IP address back.

After go-live is confirmed stable, we install caching, security, monitoring, and reporting tools on the new live environment. Once everything is in order and you have signed off, we cancel the second account and your billing returns to the single-account rate.

What to Expect Around the Time of Go-Live

A Short Window of Downtime Is Normal

The type of disruption you can expect during go-live depends on which method we use.

Method A: Expect Maintenance Mode and Caching Flutter

Because Method A does not involve a DNS change or IP update, your domain, SSL certificate, and IP address remain the same throughout. There is no blackout window where the site is completely unreachable. However, some disruption during the migration and post-migration cleanup is unavoidable:

• WordPress may display a brief maintenance notice while files are being migrated or while we are installing and configuring plugins.
• Visitors who have the old site cached in their browser may not immediately see the new design. This is normal and typically clears on its own once caching refreshes.
• If you visit the site frequently and have an aggressive browser cache, you may temporarily see a mix of old and new content. A hard refresh (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) usually resolves this.

Method B: Expect a True Cutover Window

Method B does involve an IP address change, which means there will be a true cutover window where your site may appear unavailable or insecure in browsers. This window typically lasts 15 to 90 minutes but can occasionally be longer. The main cause is SSL certificate issuance: the new hosting account needs to obtain an SSL certificate for your domain, and this cannot happen until after DNS has propagated to the new IP address. Until the certificate is active, browsers will flag the site as insecure.

The main visible symptom during this window is an SSL error—browsers will flag your site as insecure because the SSL certificate does not yet exist for your domain on the new server. Our hosting platform requests the certificate automatically once it detects that DNS is pointing to the new account, but until the certificate is issued and activated, some browsers will show a warning or refuse to load the site.

This cutover window is unavoidable with our hosting platform and cannot be eliminated. We monitor the process throughout and will let you know as soon as the certificate is active and the site is confirmed loading correctly. Please be patient—what you are seeing during this window is expected, not a sign that something went wrong.

Please Don’t Panic and Revert Your DNS

We will walk you through exactly what to expect before go-live begins, including an estimated timeline. If something still looks wrong after the expected window has passed, open a support ticket or call us—but do not change the IP address without speaking with us first.

Common Question: Can I Just Point My Domain to the Staging Site?

We occasionally get this question: “The new site looks great in staging—can we just point the domain there and skip the migration?”

The short answer is no, and there are two reasons why.

First, your staging environment shares the same IP address as your live site. You cannot point your domain to staging independently—they are on the same address. Changing the IP would just continue pointing to the same server, and visitors would still see whichever site is currently live at that location.

Second, staging environments are not built to handle production traffic. Our hosting platform allocates different resources and performance specifications to staging versus live production environments. A staging site is a workspace for building and testing—it is not sized, configured, or optimized to serve your real visitors reliably. Running production traffic through a staging environment would result in degraded performance and is not something we support.

The migration process exists specifically to move your site from its staging environment into a proper production environment. That’s what ensures it performs well for your visitors after go-live.

DNS Management: Why We Recommend Letting Us Handle It

This section applies to Method B, which involves an IP address change. If you are using Method A, no DNS changes are needed on your end.

Go-lives often happen in the evening or on weekends to minimize impact on your visitors. If we need to make a last-minute DNS adjustment at 1 a.m.—to troubleshoot SSL issuance or handle an unexpected redirect issue—and your DNS is managed through your personal registrar account, we may need to wake you up to get through a two-factor authentication prompt on your phone.

To avoid this, we strongly recommend allowing us to manage your domain’s DNS records through a dedicated DNS provider. This gives us the access we need to work quickly and confidently on your behalf at any hour, without requiring you to be available.

If you prefer to keep control of your own DNS, that’s completely fine—we just ask that you be reachable and available to make changes quickly during the cutover window.

Backups: What We Do to Protect You

Before we make any changes to your live environment, we create multiple backups. We take these steps not as a formality but because the migration process involves several steps that are difficult to reverse cleanly without a known-good restore point.

Our backup strategy includes:

• A platform-level backup of your current live environment, taken immediately before any migration work begins.
• Off-site backups through our Total Website Protection (TWP) service (if previously purchased), which keeps an independent copy of your site on infrastructure separate from your main hosting account. This protects against worst-case scenarios and is especially important for mission-critical sites.
• Ad-hoc backups at key points during the process—for example, immediately before running a database update or a URL rename operation.

We document which backup was taken at which stage, and we share that information internally so that if anything needs to be restored, we know exactly what each restore point contains.

Summary: What You Need to Do

Most of the go-live process is handled entirely by our team. Here’s what we’ll need from you:

• Review and approve the staging site before we schedule go-live.
• Let us know whether you want the standard migration or the rollback-friendly method, or we can recommend one based on your situation.
• Be available (or have a designated contact available) during the go-live window in case questions arise.
• If you manage your own DNS, be ready to make a quick IP address change when we give you the go-ahead signal, and do not revert it without checking with us first.