The step most people get wrong when connecting a custom domain to a new host is not a technical mistake. It is forgetting to preserve the email routing records during the switch, causing email to stop working entirely. I nearly made that mistake. My cursor was over the save button in my Namecheap dashboard, ready to point my domain to the new Hostinger server. Then a thought surfaced from the hours of research I had done: did I remember to copy the email records? I closed the nameserver tab and went back to my old DNS settings. What I found saved my communication from a complete blackout. That moment the hesitation before the final confirmation is the reason I am writing this article.
I had already moved the entire blog from a free platform to a self‑hosted WordPress setup. The new hosting plan was fast, the site loaded on the temporary URL, and every page had been tested. The only remaining step was connecting the domain so visitors would land on the new server. That single step determines whether the transition is invisible or whether the site goes dark, the SSL certificate breaks, and email delivery collapses. I learned that the people who get it wrong are not the ones who skip the process. They are the ones who complete every other step and then overlook one critical detail in the DNS zone.
This is the exact process I followed. It is not professional advice. It is a personal account of how I connected my domain, registered at Namecheap, to my new host at Hostinger, without losing access to email or breaking the site. Every domain, every host, every situation is different. Do your own research and decide based on your own responsibility. But if my experience can light the way, then the hours I spent documenting every DNS record were worth far more than I knew.
The difference between a flawless migration and a catastrophic one is not luck. It is a single, careful verification before you save.
The Structure of a Domain Connection: The Three Moving Parts
Before I touched a single setting, I had to understand the machinery. A domain connection is not one switch. It is a coordinated handoff between three separate entities:
1. The Domain Registrar: The company where I purchased the domain. In my case, that was Namecheap. They hold the registration, but they do not necessarily control where the domain points.
2. The DNS Manager: The phonebook of the internet. It translates the human‑readable domain into machine‑readable IP addresses. The DNS manager can be the registrar, the hosting provider, or a third party.
3. The Web Host: The server where the website files actually live. For me, that was Hostinger.
When I connect a domain to a new host I update the DNS manager to point visitors to the IP address or nameservers of the new host. The records that control this routing have specific names and functions. I documented them before making any change.
The Core DNS Records I Had to Protect
Record Type Function My Actual Setting (Example)
A Record Points the root domain (@) to an IPv4 address. The street address. @ → 192.0.2.1
CNAME Record Creates an alias, usually to point www to the root domain. The forwarding sign. www → @
MX Record Dictates where email sent to the domain is delivered. The mailbox. Priority 1 → aspmx.l.google.com
TXT Record Holds text data, most often for SPF and DKIM authentication. The security badge. v=spf1 include:_spf.google.com ~all
The A and CNAME records controlled the website. The MX and TXT records controlled email. A mistake in the first two would bring down the site. A mistake in the second two would bring down communication. Both were unacceptable. Understanding this distinction was the first step toward a safe migration.
The 48‑Hour Preparation That Made the Migration Safe
I did not flip the switch on impulse. I prepared for two full days before I made a single change to the public DNS.
Step 1: Lower the TTL to 300 Seconds
TTL Time To Live tells other servers how long to cache a record before checking for updates. The default is often 14,400 seconds (4 hours) or even 86,400 seconds (24 hours). If I changed my hosting while the TTL was still set to a full day, some visitors would be directed to the old, possibly non‑functional server for an entire day.
I logged into my Namecheap dashboard, navigated to Domain List > Manage > Advanced DNS. For every A record and CNAME record, I selected the TTL dropdown and chose Custom, entering 300 seconds. This simple action told every DNS server worldwide to remember my records for only five minutes. When I eventually made the switch, the old records would expire from caches globally within minutes. Propagation the ripple effect of the change across the internet would be measured in minutes, not days.
Step 2: Document Every Existing DNS Record
I opened a blank spreadsheet and created columns for Record Type, Host, Value, TTL, and Priority. Then I went through the Namecheap DNS zone line by line, copying every entry:
· The A record for the root domain (@) pointing to the old host’s IP.
· The CNAME record for www pointing to the root.
· Every MX record, with exact priority numbers and values (mine pointed to Google’s mail servers).
· Every TXT record, including the long SPF string and DKIM key.
I took screenshots and saved the spreadsheet to a safe location. This documentation was my safety net.
Step 3: Full Backup of the Old Site
I downloaded all website files and exported the database. The old hosting account would stay active for at least a week, but having a local copy gave me control. These three actions lowering TTL, documenting DNS, and backing up the site took less than an hour and cost nothing. They transformed the migration from a gamble into a controlled, verifiable process.
Setting Up the Destination: Adding the Domain to Hostinger
The domain could not be pointed to Hostinger until Hostinger was ready to receive it. I logged into my Hostinger dashboard the managed WordPress environment I chose after researching selecting hosting plan that prioritizes speed and scalability and navigated to Websites > Add Website. I entered my custom domain name.
Hostinger generated two critical pieces of information: a temporary URL for private testing, and the IP address of the new server. I wrote that IP address on a sticky note. It would become the target of my DNS update.
The Hosts File Trick for Private Testing
I wanted to verify the site on the new server without the rest of the world seeing it. I edited my computer’s hosts file a plain text file that maps domain names to IP addresses before checking public DNS.
On Windows:
· Open Notepad as Administrator.
· Open C:\Windows\System32\drivers\etc\hosts.
· Add a line: [New Hostinger IP] yourdomain.com
· Add another line: [New Hostinger IP] www.yourdomain.com
· Save the file. Then open Command Prompt and type ipconfig /flushdns.
On Mac:
· Open Terminal and type sudo nano /etc/hosts.
· Add the same two lines with the new IP and your domain.
· Press Ctrl+O, Enter to save, then Ctrl+X to exit.
· Type sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
Now, only my computer saw the site loading from Hostinger. I tested every page, every internal link, and every form. Once everything worked, I was ready.
The Two Methods and the One That Saved My Email
There are two ways to connect a domain to a new host the choice between them is the most important decision in the entire migration.
Method A: Changing Nameservers
This method hands full DNS management to the new host. I log into Namecheap, find the Nameservers setting, and replace the existing Namecheap nameservers with the Hostinger nameservers. Once saved, the entire DNS zone moves to Hostinger. The website points to the new server automatically. It seems simpler one change, done.
The hidden danger: When nameservers switch, the DNS zone at Hostinger starts blank, or with basic defaults. Every custom record that existed at Namecheap especially MX records for email and TXT records for authentication is wiped clean unless I manually recreate them before the switch. If I forget even one record, email delivery collapses. This is the step most people get wrong.
Method B: Updating the A Record Only
This method leaves the nameservers at Namecheap and updates only the record that controls website traffic. I locate the A record for @, change its value from the old IP to the new Hostinger IP, and update the CNAME for www to point to the root. That is it. The MX records, TXT records, and any other subdomain records remain untouched because the DNS manager never changed. The website moves. The email stays exactly where it was.
I chose Method B. My email was too important to risk. The A record method isolates the migration to the website alone. The risk of an email blackout was eliminated by design.
The Step Most People Get Wrong
The step most people get wrong is not a missing button. It is the failure to preserve email routing and authentication records when switching nameservers. Here is the exact scenario that plays out daily:
1. A site owner buys a new hosting plan.
2. They log into their registrar and change the nameservers to the new host.
3. The website loads perfectly. They celebrate.
4. The next morning, clients report bouncing emails. The owner tries to send a message and gets an error.
5. Panic sets in.
Why it happens: The old DNS zone had MX records pointing to Google Workspace or Microsoft 365, and TXT records for SPF and DKIM that proved emails were legitimate. When the nameservers changed, the new host created a default zone with no knowledge of those records. Email delivery collapsed. Missing SPF/DKIM records sent any surviving messages to spam.
The DNS Mirror Strategy
If I had been forced to use the nameserver method, I would have executed the DNS Mirror Strategy before switching:
1. Export or copy every non‑website record from the old DNS: all MX records with exact priority numbers, all TXT records (SPF, DKIM, any verification strings).
2. Log into the new host’s DNS manager.
3. Manually recreate every single record exactly as it was on the old host.
4. Only after the new DNS zone was a perfect mirror of the old one (minus the old website A record) would I change the nameservers.
For example, my Google Workspace MX records looked like this before the migration:
· Priority 1 → aspmx.l.google.com
· Priority 5 → alt1.aspmx.l.google.com
· Priority 5 → alt2.aspmx.l.google.com
· Priority 10 → alt3.aspmx.l.google.com
· Priority 10 → alt4.aspmx.l.google.com
My SPF TXT record was: v=spf1 include:_spf.google.com ~all
If I had switched nameservers without mirroring those records, every single one of those email protections would have vanished instantly.
The nameserver switch takes seconds. The email recovery takes days. The verification check takes minutes. That trade‑off is never worth it.
The Execution: Updating the A Record on Namecheap
With the preparation complete and the method chosen, I returned to my Namecheap dashboard. I navigated to Advanced DNS for my domain. The spreadsheet of old records was open on my second screen.
Step-by-Step on Namecheap
1. Locate the A record with Host set to @. This controls the bare domain.
2. Select the edit icon. In the Value field, delete the old IP address and type the new Hostinger IP. Double‑check every digit. A single mistyped number sends visitors nowhere.
3. Verify the TTL is still 300 seconds.
4. Locate the CNAME record for Host www. Ensure the Value points to @ (the root domain).
5. Save all changes.
That was the entire execution phase. Two record edits. A verification. A confirmation. The website was now directed to Hostinger. The MX records for email remained untouched. The TXT records for authentication remained untouched.
Monitoring Global Propagation
DNS propagation is not instantaneous. I opened dnschecker.org, typed in my domain, selected A from the dropdown, and searched. The map showed green checkmarks where servers had updated to the new IP, and red X’s where they still pointed to the old one. Within thirty minutes, most of the world showed green. Within an hour, the transition was complete.
Clearing Local Cache
At one point, the global checker was fully green, but my browser still displayed the old site. My local machine was caching the old DNS response. I flushed the OS DNS cache and cleared my browser data. The new site appeared instantly. This is a common source of confusion the problem is not the migration but the local machine holding onto outdated information.
Verifying That Everything Survived the Migration
The website loaded that was the first test. But a website loading does not mean the migration is complete. I ran a full verification checklist.
1. SSL Certificate
I typed https:// before my domain and checked for the padlock. Hostinger had provisioned a free SSL certificate through Let’s Encrypt. The connection was encrypted. Every page loaded securely. If the padlock had not appeared, I would have triggered a manual SSL issuance in the Hostinger control panel.
2. Email Deliverability Test
This was the test I was most anxious about, even though I knew the records were untouched.
· I sent an email from my domain address to a personal account. It arrived in the inbox, not spam.
· I replied from the personal account back to my domain. It arrived.
· I checked the email headers. They displayed SPF: PASS and DKIM: PASS. The authentication records were intact.
3. Site Performance
I ran the domain through Google Page Speed Insights. The scores matched what I had seen on the temporary URL 95 to 99 on mobile, 97 to 100 on desktop. The migration had not degraded performance.
4. Internal Links
I followed a dozen internal links. Every one resolved correctly. The library was intact, and the architecture that connects readers from one resource to another was functioning perfectly.
The 7‑Day Email Monitoring Protocol
After the migration I did not assume email was working just because a single test message arrived. I set up a daily verification routine that I followed for seven consecutive days.
Day 1: I sent a test email from my domain to Gmail, Yahoo, and Outlook addresses. All three arrived in the inbox. I replied from each. The replies reached my domain inbox. I checked the headers of the received messages and confirmed SPF, DKIM, and DMARC all showed PASS.
Day 2: I sent an email with an attachment. It delivered without issue. I checked the spam folder of the receiving account nothing from my domain was there.
Day 3: I sent from a different device, using a different network. Same results. This confirmed the DNS changes had propagated globally and no regional caching was causing issues.
Day 4: I asked a colleague to send me an email from their domain. I received it. I replied. They received my reply. This tested the full round‑trip.
Day 5: I checked the email logs in Google Workspace. No messages were queuing or bouncing. Everything was flowing normally.
Day 6: I tested the contact form on my website. The notification email arrived in my inbox. The sender received the auto‑reply.
Day 7: I declared email migration complete and recorded the results.
This daily verification gave me confidence that the DNS settings were correct and permanent. It turned a one‑time test into a thorough validation. The small time investment each day was worth the certainty it provided.
Post‑Migration Lockdown: Securing the New Setup
A premium migration does not end when the site loads. It ends when the new configuration is locked against future problems.
Increase TTL Back to Normal
With the migration stable, I returned to Namecheap and increased the TTL to 14,400 seconds (4 hours). The low TTL had served its purpose during propagation. A permanently low TTL increases query load and can slightly slow repeat visitors.
Enable Domain Lock
I toggled the Domain Lock setting at Namecheap to ON. This prevents unauthorized transfers of the domain to another registrar.
Enable DNSSEC
I checked whether Namecheap and Hostinger supported DNSSEC Domain Name System Security Extensions. It adds cryptographic signatures to DNS records, preventing attackers from redirecting the domain via cache poisoning. It was supported, so I enabled it.
Update Third‑Party Integrations
My Google Search Console verification remained intact because the TXT record never moved. Analytics tracking continued without interruption. I checked server error logs on Hostinger for any 404 errors. The logs were clean.
The 7‑Day Observation Period
I kept the old hosting account active for a full week. I monitored traffic, checked email delivery daily, and watched for any anomalies. After seven days with zero issues, I canceled the old plan the migration was permanently complete.
Common Post‑Migration Issues and How I Prepared for Them
Even with careful preparation, things can go wrong. I researched the most common post‑migration issues and documented the fixes, so if I encountered them I would know exactly what to do. I share these not because I experienced them all, but because being prepared for them is part of a premium migration.
Symptom Likely Cause The Fix
“This site can’t be reached” (ERR_CONNECTION_REFUSED) The new host does not have the domain added to its server block or virtual host. Log into the new host. Ensure the domain is explicitly added to the hosting account, not just parked.
Website loads, but CSS/images are broken Mixed Content error or cached assets. Ensure the site URL in the CMS is updated to https://. Clear any server‑side cache.
“Your connection is not private” (SSL Error) SSL certificate has not been issued on the new host. Trigger a new Let’s Encrypt or AutoSSL issuance in the new host’s control panel.
Emails are going to Spam Missing SPF or DKIM records after migration. Copy the exact TXT records for SPF/DKIM from the email provider to the active DNS manager.
Propagation is stuck on old IP for > 24 hrs TTL was not lowered beforehand, or a locked registry. Wait it out. There is no “force update” button for global DNS. Ensure the TTL was actually set to 300, not accidentally to 86400.
www version not loading CNAME record misconfigured or missing. Verify the CNAME for www points to @ or the root domain.
Email sent but never received MX records missing or incorrect priority. Check the MX records against the email provider’s documentation. Ensure priorities match exactly.
Subdomain not working The subdomain’s A or CNAME record was lost during nameserver switch. Recreate the subdomain record in the active DNS manager.
This table is not a substitute for professional support, but it gave me a starting point if something went wrong. I kept it open in a browser tab for the first week after migration.
The Complete Pre‑Migration and Post‑Migration Checklist
This is the checklist I built from this experience. It is not a professional template it is what worked for me, and I share it as a reference for anyone walking a similar path.
48 Hours Before Migration
· Backup all website files and databases from the old host.
· Document every existing DNS record: A, CNAME, MX (with priority numbers), TXT.
· Take screenshots of the entire DNS zone.
· Lower TTL on all A and CNAME records to 300 seconds.
· Confirm access to both the old and new hosting control panels.
· Confirm access to the domain registrar.
A Few Hours Before
· Add the domain to the new hosting control panel.
· Note the new host’s IP address.
· Edit the local hosts file to test the new site privately.
· Verify every page, form, and internal link works on the new server.
· If changing nameservers, recreate all MX and TXT records in the new host’s DNS manager before switching.
Execution
· Update the A record to the new IP address (preferred) or change nameservers (only if the DNS mirror is complete).
· Save changes at the domain registrar.
· Open a propagation checker (dnschecker.org) and monitor.
Within the First Few Hours
· Monitor global propagation until all locations show green.
· Flush local OS and browser DNS caches.
· Verify the live site loads with https:// and a valid padlock.
· Send test emails in both directions and check headers for SPF/DKIM PASS.
· Run a PageSpeed Insights test to confirm no performance degradation.
Daily for 7 Days
· Send a test email from domain to Gmail, Yahoo, Outlook.
· Check email headers for authentication PASS.
· Verify the contact form is delivering notifications.
· Check Google Search Console for any crawl errors.
· Monitor server error logs on the new host.
After 7 Days
· Increase TTL back to 14,400 seconds (4 hours).
· Verify no errors in Google Search Console.
· Confirm Domain Lock is enabled.
· Enable DNSSEC if supported.
· Cancel the old hosting account.
Understanding SPF, DKIM, and DMARC: The Email Authentication Trio
The MX records route email, but the TXT records prove the email is legitimate. Without them, email from my domain would be marked as spam or rejected entirely. I learned exactly what each one does before the migration.
SPF (Sender Policy Framework): This TXT record lists the servers authorized to send email on behalf of my domain. My SPF record was v=spf1 include:_spf.google.com ~all. This tells receiving servers: “Only Google’s mail servers are allowed to send email from this domain. Treat anything else with suspicion.” If I had lost this record, every email I sent would have failed SPF checks and landed in spam folders.
DKIM (DomainKeys Identified Mail): This adds a cryptographic signature to every outgoing email. The public key is stored in a TXT record (under the google._domainkey host). Receiving servers use this key to verify that the email was not tampered with during transit and that it genuinely originated from my domain. Without DKIM, emails lack a critical layer of trust.
DMARC (Domain‑based Message Authentication, Reporting, and Conformance): This TXT record tells receiving servers what to do with emails that fail SPF or DKIM checks quarantine them, reject them, or let them through. It also provides reporting so I can see who is sending email using my domain. My DMARC record was set to v=DMARC1; p=none; rua=mailto:…, which allowed monitoring without blocking. During migration, I verified that this record was still in place.
These three records form a chain of trust. If any link in the chain breaks during a DNS migration, email deliverability suffers. The A record method kept them safe by leaving them untouched. If I had used the nameserver method, I would have had to manually recreate every one of these records on Hostinger before the switch.
Structure of a DNS Zone: How the Records Work Together
A DNS zone is not a random collection of records. It is a structured set of instructions that tell the internet how to handle every request for my domain. Understanding how the records interact helped me see why the migration had to be precise.
When someone types dailingua.com into a browser, the DNS resolver first checks the NS records to find out which DNS manager is authoritative. Since I left the nameservers at Namecheap, the resolver queries Namecheap’s DNS servers. It then looks for the A record to find the IP address. If the visitor typed www.dailingua.com, the resolver follows the CNAME record to the root domain and then checks the A record.
For email, when someone sends a message to hello@dailingua.com, the sending server queries the MX records to find the mail server. It then checks the SPF and DKIM TXT records to verify the sending server’s identity. If any of these records are missing, the email either bounces or lands in spam.
The A record method preserved this entire structure. Only one line the A record’s IP address changed. Everything else remained as it was, tested and working. This is why documenting the zone before making changes is essential: you need to know what a correct zone looks like so you can verify it after the change.
My Actual DNS Configuration (Before and After)
To make this guide as concrete as possible, I am sharing the exact DNS records I managed during my migration. The IP addresses have been replaced with placeholders, but the structure is identical.
Before Migration (Old Host):
Type Host Value TTL Priority
A @ 203.0.113.1 (old host) 300
CNAME www @ 300
MX @ aspmx.l.google.com 14400 1
MX @ alt1.aspmx.l.google.com 14400 5
MX @ alt2.aspmx.l.google.com 14400 5
MX @ alt3.aspmx.l.google.com 14400 10
MX @ alt4.aspmx.l.google.com 14400 10
TXT @ v=spf1 include:_spf.google.com ~all 14400
TXT google._domainkey k=rsa; p=MIGfMA0GCSq… 14400
After Migration (New Host):
Type Host Value TTL Priority
A @ 192.0.2.1 (Hostinger IP) 300 → 14400
CNAME www @ 300 → 14400
MX @ aspmx.l.google.com 14400 1
MX @ alt1.aspmx.l.google.com 14400 5
MX @ alt2.aspmx.l.google.com 14400 5
MX @ alt3.aspmx.l.google.com 14400 10
MX @ alt4.aspmx.l.google.com 14400 10
TXT @ v=spf1 include:_spf.google.com ~all 14400
TXT google._domainkey k=rsa; p=MIGfMA0GCSq… 14400
The only records that changed were the A record and the CNAME record. The MX records, TXT records, and all email‑related settings remained identical. This is the power of the A record method. The website IP changed, but the email infrastructure was untouched.
The Moment of Verification: What I Checked Before I Saved
Before I saved the A record change, I ran through a final verification in my head. I share this because the mental checklist I used might help someone else.
1. Is the TTL still set to 300? Yes. I had checked it twice.
2. Is the new IP address correct? Yes. I had copied it directly from the Hostinger dashboard and verified it against the temporary URL.
3. Are the MX records still present and unchanged? Yes. I could see them in the Namecheap DNS zone, identical to my spreadsheet.
4. Are the TXT records (SPF and DKIM) still present? Yes. Both were there.
5. Is the CNAME for www pointing to the root? Yes.
6. Do I have the old hosting account still active as a fallback? Yes. The old site was still running.
Only after I could answer yes to every question did I save the change. That mental checklist prevented the disaster that plays out when someone rushes the process.
Walkthrough: The Namecheap Advanced DNS Interface in Detail
When I first opened the Namecheap Advanced DNS page, the interface felt dense. Here is exactly what I saw and how I navigated it.
The page has two main sections: Nameservers and Host Records. The Nameservers section shows which DNS provider is authoritative. I left this set to Namecheap BasicDNS.
The Host Records section contains a table. Each row has columns for Type, Host, Value, TTL, and (for MX records) Priority. To edit a record, I selected the small pencil icon. The fields became editable. I changed the Value, selected a new TTL from the dropdown, and selected the checkmark to save.
At the top of the Host Records section, there is an Add New Record button. I used this during preparation to practice, but during the actual migration I only edited existing records.
I also used the Advanced DNS tab to manage DNSSEC later. The main work happened in the Host Records table. The interface, once I understood it, was straightforward. The anxiety came from the stakes, not the complexity.
Decision Guide: Which Method You May Use?
You use a third‑party email provider (Google Workspace, Microsoft 365) Method B (A Record Only) Preserves MX and TXT records automatically. No risk of email blackout.
You want the new host to manage all DNS Method A (Nameservers) with DNS Mirror Only if you manually recreate every email record on the new host first.
Your DNS is managed at your registrar and you are comfortable editing records Method B Faster, safer, and isolates the migration to the website only.
You are moving email hosting along with web hosting Method A You will need to set up new email records on the new host anyway.
You are unsure about DNS and want the simplest path Method B Fewer things to break. One IP address change. Done.
For my situation Google Workspace email, Namecheap registrar, Hostinger host Method B was the clear winner. The decision took less than a minute once I understood the stakes.
What I Wish I Had Known Before Starting
Before this migration, I did not know the difference between an A record and an MX record. I did not know what TTL stood for. I did not know that changing nameservers could wipe my email settings. I learned all of this through research, and I am sharing it so that someone else can learn from my experience rather than from their own mistakes.
The single most important thing I learned: document everything before you change anything. A screenshot of your DNS zone costs nothing and can save days of recovery. The second most important: use the A record method unless you have a compelling reason not to. It is the safest path for most migrations. The third: test privately using the hosts file. There is no reason to make a change public before you know it works.
These three lessons, applied together, turned a high‑stakes technical migration into a calm, controlled process.
The Day After Migration: What I Checked Every Morning
For the seven days following the migration, I followed a morning routine. I opened three tabs: my website, my email inbox, and dnschecker.org. I confirmed the site loaded with the padlock. I sent a test email. I checked the propagation map, though after the first day every location showed green. This routine took less than five minutes but gave me daily confirmation that nothing had silently broken.
On the third day, I also checked Google Search Console for any crawl errors. There were none. On the fifth day, I reviewed the email logs in Google Workspace. No messages had bounced. On the seventh day, I canceled the old hosting plan.
This daily discipline the consistency that builds a publishing cadence over time applied to migration verification. Small, repeated checks catch problems that a single test might miss.
Final Checklist Summary Phase And Action (One‑Page Version)
48 hrs before Backup site and database. Document all DNS records. Lower TTL to 300s.
2 hrs before Add domain to new host. Note new IP. Test via hosts file. If using Method A, mirror MX/TXT records on new host.
Execution Update A record (or change nameservers if mirror complete). Save. Monitor dnschecker.org.
First hours Flush DNS cache. Verify HTTPS padlock. Send test emails both ways. Check SPF/DKIM headers.
Before Daily 7 days Send test emails. Check spam folders. Monitor error logs and Search Console.
After 7 days Increase TTL to 14400. Enable Domain Lock and DNSSEC. Cancel old hosting.
This Migration Was a Step in a Larger Journey
Connecting a domain to a new host was not an isolated technical task. It was one step in the larger journey of building a digital asset that would serve readers for years. The same care I applied to this migration preparation, documentation, verification is the care I apply to every article I publish. The foundation must be solid because everything else rests on it.
When I look at the site now, loading fast, serving readers, growing article by article, I do not think about DNS records. I think about the next article. And that is the point. The technical foundation fades into the background, doing its job silently, so the content can shine.
The Long‑Term Confidence That Came From a Clean Migration
Months later, I still remember the migration. Not because anything went wrong, but because everything went right. The site loads fast. The email delivers reliably. The SSL certificate renews automatically. I have not had to touch the DNS settings since the day I increased the TTL back to normal.
That confidence is the reward of a careful migration it allows me to focus entirely on building the library writing articles, improving old content, connecting readers to resources. The technical foundation is invisible, which is exactly what a foundation should be. I built it once, correctly, and now it supports everything else.