Migrating your domain name and DNS settings away from NCR

Moving away from NCR Retail Online involves more than choosing a new ecommerce platform. Your domain name, DNS records, email services, SSL certificates, redirects, and integrations all need to move in a controlled sequence. A rushed change can make a storefront unavailable, interrupt business email, or prevent customers from reaching checkout.

NCR Retail Online was discontinued, requiring merchants to transition to alternative systems such as Magento and WooCommerce through NCR Counterpoint partners. The safest approach is to treat the migration as a coordinated infrastructure project rather than a simple domain transfer.

The domain itself may be registered with one company while DNS is hosted by another. Identifying those separate roles early helps prevent accidental expiration, broken records, and uncertainty about who controls the website address.

Understand what must be moved

A domain transfer changes the registrar responsible for the domain registration. It does not automatically copy your DNS zone, website files, email configuration, or application settings. Before requesting a transfer, record the domain’s current registrar, expiration date, administrative contact, nameservers, and transfer-lock status.

DNS hosting is a separate concern. Your nameservers determine where records are managed, while individual records direct traffic to web servers, mail providers, payment tools, verification services, and third-party applications. If the domain remains with the existing registrar but nameservers move to a new DNS provider, the result can be similar to a registrar migration, but the steps and risks differ.

Create an inventory of every hostname in use, including the main domain, “www” address, checkout subdomain, staff portal, API endpoint, and email-related records. Include A, AAAA, CNAME, MX, TXT, SRV, and CAA records where applicable. Screenshots are useful, but an export or written record is more reliable.

Audit the current NCR setup

Review the live storefront before changing anything. Test product pages, category pages, cart behavior, account access, checkout, order confirmation, and contact forms. If your store has a path structure similar to an existing retail catalog, preserve important URLs such as accessories listings when rebuilding the site.

Pay particular attention to integrations that may be invisible to ordinary visitors. Shipping calculators, tax services, inventory synchronization, marketing pixels, payment gateways, and order-processing applications may rely on DNS records or fixed callback URLs. Document the provider, purpose, login owner, and replacement endpoint for each one.

Also check whether email uses the same domain. MX records, SPF, DKIM, and DMARC policies should be captured before the migration. Losing one TXT record can cause messages to fail authentication or land in spam, even when the new storefront appears to work normally.

Prepare the replacement platform

Select and configure the replacement ecommerce environment before changing DNS. Magento and WooCommerce can support different hosting models, extensions, inventory connections, and security controls, so confirm that the new store is ready to receive production traffic. Load products, customer-safe content, shipping rules, tax settings, payment methods, and tracking configurations in advance.

The replacement system should provide a temporary staging address or preview environment. Use it to test responsive layouts, product search, filtering, checkout, transactional emails, and order creation. Where possible, place the new store behind its final domain on a private or restricted setup so SSL and host-based behavior can be verified before launch.

Make a redirect map from old URLs to their corresponding new locations. Preserve high-value product and category paths when they still make sense, and use permanent redirects for pages that have moved. Avoid sending every old URL to the homepage, since that weakens search visibility and creates a poor customer experience.

Plan the DNS cutover

Lower DNS record time to live, or TTL, before the change. A setting such as 300 seconds can help resolvers refresh records sooner, although some networks and devices may cache information longer than the stated TTL. Make this adjustment at least a day before the planned cutover when possible.

At launch, update only the records that need to change. A typical web migration may involve replacing the A record for the root domain and the CNAME for “www,” while leaving MX, SPF, DKIM, verification, and service records untouched. If the new provider requires nameserver changes, copy the entire DNS zone first and compare it carefully with the original.

Do not cancel the old NCR-related service immediately. Keep the previous environment available during propagation and validation. DNS resolution varies by location and provider, so a portion of customers may still reach the old server for several hours. A transition window allows errors to be corrected without taking the entire business offline.

Compare migration paths

The best approach depends on whether you are changing only the web host, moving DNS management, transferring the registrar, or replacing the whole commerce stack. Separating these decisions reduces the number of variables changed at one time.

A registrar transfer is often best performed separately from a website launch. First stabilize the replacement store and DNS, then move the domain registration after access, billing, and renewal ownership are confirmed. This staged method makes troubleshooting easier because a domain-control issue cannot be confused with an application outage.

Protect operations during the transition

Security should be part of the migration checklist. Use multi-factor authentication on the registrar, DNS provider, hosting account, and ecommerce administrator accounts. Limit access to people who need it, verify the destination nameservers through a trusted channel, and review domain-lock settings before initiating a transfer.

Confirm that the new platform has a valid TLS certificate for every public hostname. Test both the root domain and “www” version, and decide which one should be canonical. Check HTTP-to-HTTPS redirects, cookie security, checkout callbacks, and any content security policy that could block payment or analytics scripts.

Operational continuity also depends on order handling. Export or reconcile open orders before the cutover, verify inventory quantities, and establish a manual fallback for orders placed during propagation. NCR’s product discontinuation can affect multi-channel workflows, so reviewing multi-channel selling impacts can help identify marketplace, store, and fulfillment dependencies that require extra testing.

Validate after the records change

DNS propagation is not a single event. Query the domain from several public resolvers and geographic locations, then confirm that each returns the intended address. Check the site using mobile data as well as office or home broadband, since local caches can conceal a problem.

Run a production test order with a low-risk product or a controlled payment method. Confirm that the order reaches the correct system, inventory is reduced once, confirmation email is delivered, and shipping or tax information is correct. Test refunds, abandoned-cart messages, customer login, and administrator notifications if those functions are important to daily operations.

Review server logs, uptime monitoring, search-console coverage, analytics activity, and payment-provider dashboards for at least several days. Watch for 404 errors, certificate warnings, mail delivery failures, and unexpected traffic drops. Keep a dated record of every DNS change, test result, and rollback decision.

Keep the replacement stack manageable

A successful migration should leave the business with clear ownership and documented procedures. Record the registrar account, DNS host, hosting provider, renewal dates, nameservers, zone export, SSL renewal method, and emergency contacts in a secure password manager or controlled operations document.

Review the order automation architecture as well. If the former system connected online sales with inventory and fulfillment, compare replacement tools for synchronization frequency, duplicate-order protection, failure alerts, and manual recovery. A review of replacement order tools can support that assessment without assuming that every store needs the same integration pattern.

Use these migration priorities when assigning work:

• Assign one owner for the domain, DNS, and registrar changes.
• Export the complete DNS zone and verify email records before editing anything.
• Finish the replacement store and redirect map in a staging environment.
• Schedule the cutover during a low-order period with technical support available.
• Monitor storefront, email, payments, inventory, and search visibility after launch.

Once the new site is stable, remove obsolete records, revoke former administrator access, and cancel legacy services only after confirming that no email, integration, or reporting function still depends on them. Place a calendar reminder for domain renewal and conduct a quarterly DNS review.

Begin by documenting the current domain and DNS configuration, then coordinate the new platform, registrar, and hosting provider around a written cutover window. Careful preparation turns the move away from NCR into a controlled transition that protects storefront availability, customer trust, and ongoing online sales.