How I rebuilt and migrated a flat-file author website without breaking its subdomains

The question I needed to answer

Could I move the main GlenisGraham.com website to Hostinger without interrupting subdomains that were still hosted elsewhere?

The answer was yes, but only if I treated the website, DNS authority, and individual DNS records as separate parts of the system. Changing where the root domain points is not the same as changing the domain’s nameservers.

What I found during discovery

The existing GoDaddy account used cPanel web hosting and contained many unrelated websites, subdomains, email accounts, and databases. The Glenis Graham website itself was a flat-file site. Its working content consisted of HTML, CSS, JavaScript, JSON, and image files. It did not need a database to display the catalog.

A database export existed, but the current site did not depend on it. I treated that export as legacy material rather than importing it into the new production system.

This distinction mattered. Migrating an unused database would have added risk without adding value.

The controlled migration sequence

1. Capture the baseline. I collected the website archive, hosting screenshots, document-root information, and available backup evidence before changing production.
2. Classify the architecture. I confirmed that the current site could run as flat files and that the database was not part of the active website.
3. Create a dedicated repository. I placed only this website in its own private GitHub repository. It remains separate from every other brand and website project.
4. Make GitHub the source of truth. Changes now move through feature branches, pull requests, owner approval, merges to the main branch, deployment, and live verification.
5. Deploy to a temporary Hostinger address. This allowed the reconstructed site to be reviewed before the public domain moved.
6. Change only the website records. The root A record was pointed to Hostinger, and the www record was directed to the root domain. The nameservers stayed where they were.
7. Wait for SSL and verify HTTPS. The site was tested after the certificate became active and the secure address resolved correctly.

Why the subdomains stayed online

Nameservers decide which DNS provider is authoritative for the entire domain. Replacing them without recreating every required record at the new provider could disrupt subdomains, email, verification records, and other services.

I did not replace the nameservers. I edited only the root and www records inside the existing DNS zone. The records for the other subdomains continued to point to their existing destinations.

This approach allowed the main website to move independently. It also avoided turning a focused website migration into a broad infrastructure migration.

What GitHub changed about the publishing process

The old hosting account contained working files, old copies, dated backups, and unrelated projects. That made it difficult to identify the authoritative version of the site.

The dedicated repository created a clearer rule: the approved main branch is the version intended for production. Each change has a visible purpose, a review point, and a recoverable history.

The deployment process is now:

1. Create a feature branch.
2. Make and validate one focused set of changes.
3. Open a pull request.
4. Review the content and implementation.
5. Receive owner approval.
6. Merge into the main branch.
7. Allow Hostinger to deploy.
8. Verify the live HTTPS pages.

What I would do differently next time

I would begin with a complete DNS inventory, not just the records for the visible website. A domain may support many services that are not obvious from the homepage.

I would also classify every archive item before migration. Old files and databases can be valuable evidence, but they should not automatically become part of a clean deployment.

Finally, I would define the content model before rebuilding the homepage. A working website is not necessarily a complete publishing hub. The catalog, articles, series pages, reader resources, and measurement plan each need their own standard.

The practical rule

If the goal is to move only the main website, first determine whether the nameservers also control subdomains, email, and other services. When they do, changing only the necessary A and CNAME records can be safer than moving the entire DNS zone.

That is not a universal instruction. DNS configurations differ. Record the existing zone, confirm the destination values, preserve a rollback point, and verify each affected service after the change.