Network Solutions to Shopify.

What carries over, and what doesn't

Every platform migration has three categories: things that move cleanly, things that move with work, and things that simply do not move at all. Knowing which is which before you start is the difference between a planned migration and an unpleasant surprise in week three.

Usually moves cleanly: products, prices, descriptions, images, and categories. These are the parts everyone worries about and the parts that are, in practice, the most straightforward.

Moves, but needs work: product variants and options are the usual sticking point. Platforms model them differently, and a structure that made sense on one rarely maps one-to-one onto another. Order history is similar: it can be brought across as records, but see the warning below. Customer records move, with one important exception.

Does not move, on any platform:

• Customer passwords. These are stored hashed and are not transferable between platforms, by design. Your customers will need to reset their passwords on the new store. Plan the email that tells them so, because if you don't, your support inbox will explain it for you.
• Gift card balances and store credit. These need to be exported and reissued deliberately. This is one of the most commonly missed items in a migration, and it is the one most likely to produce an angry customer holding something they paid for.
• Product reviews, unless both sides use a review service that supports export. Reviews are usually tied to the platform or to an app rather than to the product record.
• Discount and coupon codes. Recreate the ones still in circulation. Anything printed, emailed, or sitting in an influencer's post is still out there.
• Subscriptions and recurring orders, which almost always need to be rebuilt and, in many cases, re-authorized by the customer.

Getting your data out

Network Solutions can export your products, your orders, and your customers, and the first thing we do on this migration is take a complete copy of all three, before anything else is planned. If an export turns out to be incomplete, that changes the shape and the effort of the whole project, and you want to know that on day one rather than day thirty.

We take those same three exports a second time, right before the cutover, to pick up everything that changed while the new store was being built. That second pass is covered in the cutover section below. The first pass is the one the whole build is based on.

Whatever the export gives you, verify it before you trust it. Count the products in the file against the count in the store admin. Spot-check a handful of products with complicated options against their live pages. Open the file in something that will not silently reformat it, and check that special characters, leading zeros in SKUs, and multi-line descriptions all survived. Exports that are quietly missing ten percent of a catalog are common and are much cheaper to catch now than after launch.

Moving DNS and email out first

On many Network Solutions stores, the domain, its DNS, and the business email are all with Network Solutions as well. That makes this more than a store move. If DNS and email are left where they are until launch day, the cutover becomes a nameserver change under pressure, with the inbox at stake. So we move them early, before the store work starts, while nothing is urgent.

1. Mirror every DNS record to the domain registrar. Every record that exists at Network Solutions is recreated, exactly, at the registrar's DNS (or an independent DNS host). The result is a second copy of your DNS that answers identically.
2. Change the nameservers to point at that copy. Because the records match, nothing visible changes for visitors or for email. What has changed is that your DNS no longer depends on the platform you are leaving. From here on, every later change is a single record edit rather than a nameserver move.
3. Lower the TTL. With DNS now in your own hands, the time-to-live on the records that will change at cutover is reduced, so that when the switch happens it propagates in minutes rather than over a day.
4. Set up email at the new provider and sync it across. Mailboxes are created at the new email provider and the existing mail is synced over, so the new inbox is already populated and waiting. The switch itself happens at cutover, and mail is synced a second time just before it.

Doing this first turns the riskiest part of a platform move into the least eventful one. If the mechanics are unfamiliar, the DNS guide explains nameservers, records, and TTL from scratch, and the email authentication guide covers the records that keep your mail out of spam after a move.

Building the Shopify side

The new store gets built while the old one keeps selling. Nothing about this phase should be visible to your customers, and nothing should point at the new store until it is finished and checked.

The catalog: bulk sheet first, API afterwards

The exported product data is reshaped to fit the bulk import spreadsheet Shopify supplies, and loaded that way. It is possible to create products through Shopify's API instead, and for a small catalog either works. For a large one we prefer the sheet: Shopify processes it in the background at its own pace, which for a big catalog can take a while, and nobody has to sit and watch an import job run. Once the products exist, later updates are made through the API, which is faster and more precise for changes than re-uploading a sheet.

Catalog structure comes before catalog data. Collections, and the product metadata fields that drive them, are designed alongside the theme so that products are imported into a structure that has been thought about, rather than into a flat list that gets reorganized later.

Customers and order history

Customer records are created through the API. Historical orders are imported as records against those customers, which is what makes last year's order searchable when a customer asks about it.

Everything else the store needs

• Shipping profiles and tax, set up to match what the existing store does, then confirmed with real test transactions covering the shipping and tax cases that actually apply to how you sell.
• Theme. Your existing look carried over, or a new theme set up if the move is a good moment to change it. The theme work and the collections work happen together, since one shapes the other.
• Apps and integrations reconnected: accounting, shipping, email marketing, and anything else that talked to the old store.

The redirect map: the part that protects your rankings

If you take one thing from this guide, take this section. Everything else can be fixed after launch. Search rankings, once lost, come back slowly if they come back at all.

When your store moves, every URL changes. Search engines have those old URLs indexed. Other sites link to them. Customers have them bookmarked. A redirect tells search engines that a page has permanently moved to a new address and that the ranking it earned should follow it there.

Build the map like this:

• Export the complete list of current URLs before you lose access to anything. Products, categories, content pages, and anything else that returns a page. Crawl the live site to catch pages the admin does not list.
• Find out which of them matter. Pull the pages that actually receive search traffic from your analytics, and the pages that have inbound links from other sites. In most stores a small fraction of URLs carries the overwhelming majority of the value. Those are the ones that must be correct.
• Map each old URL to its specific new equivalent. One-to-one. The product page goes to the product page.
• Use permanent redirects (301), not temporary ones. A temporary redirect tells search engines to keep the old URL indexed, which is the opposite of what you want.
• Don't forget category and content pages. Category pages often rank for broader, more valuable terms than individual products do.

Review, training, and testing

Before anything is switched, three things happen with you rather than for you.

• Product review. We go through the product information together, including the attributes, collections, and metadata fields that were built for the new store, and confirm it is correct. You know the catalog better than any import does.
• Training and documentation. Your team is trained on the new store, and we provide written documentation for the tasks you will do most often, so that the day after launch nobody is guessing how to add a product or process a refund.
• Testing. The theme is finished and tested, and then the store is tested as a whole: real orders placed with real cards, shipping and tax checked against the cases that apply to you, and every integration confirmed to be talking to the new store.

The cutover

Cutover is the moment the domain stops pointing at the old store and starts pointing at the new one. Because DNS was moved to the registrar earlier, the switch itself is a record edit, not a nameserver change, and it is short. It is still the part worth rehearsing. This is the order it runs in:

1. Pick a quiet window for your store's traffic pattern, and avoid your busiest season entirely. Nobody should be migrating a store in the run-up to their peak trading period.
2. Take a fresh export of customers and orders, and of any products added since the first export, and bring those changes into Shopify. The new store now matches the old one up to the minute.
3. Sync email a second time, so the new mailboxes hold everything received since the first sync.
4. Confirm the redirects are loaded and working. They need to be live the moment traffic arrives at the new store, not added afterwards.
5. Switch DNS for both the website and email. The website records are pointed at Shopify and the mail records at the new email provider. With the TTL already lowered, the change reaches most visitors within minutes.
6. Watch it happen. We monitor the switch as it propagates: the store loading on the domain, checkout working, mail arriving at the new provider, and the integrations still connected.

One thing to plan for rather than be surprised by: however quiet the window and however low the TTL, some visitors and some mail servers will still be using the old addresses for a short time after the switch. That is how DNS works. So we do a final sweep of the old system, usually more than one, to catch any orders or emails that landed there during the transition and handle them by hand. The old store is kept accessible after cutover for exactly this reason, and for checking things against it later.

The first weeks after

Launch is not the end of the migration. The first weeks after are when problems surface, and it is also the window in which they are cheap to fix. Monitoring and testing continue, and so does support, because the questions your team has in week one are different from the ones they had in training.

• Submit a new sitemap to Google Search Console and Bing Webmaster Tools, and watch for crawl errors. Rising 404s mean redirects were missed.
• Watch your top pages specifically. Track the URLs you identified as valuable and confirm they are being crawled and are still ranking.
• Test checkout again on the live store, with a real card. Test environments and production are not always identical.
• Expect a temporary ranking dip. A modest, short-lived fluctuation after a well-executed migration is normal while search engines reprocess the site. A large sustained drop is not, and usually means redirects.
• Watch your support inbox for patterns. Several people reporting the same confusion is a sign something needs fixing, most often the password reset.
• Keep the old system for a while. Beyond the transition sweeps, you will want to check things against it, probably more than once, and your records requirements may need it longer than you expect.

---

Most of the risk in this migration sits in three places: what you export and when you export it, whether DNS and email are moved deliberately and early rather than at the last minute, and whether the redirects are right. Get those three correct and the rest is work rather than jeopardy.