DNS Cutover and Go-Live: Migrating skylinerenting.eu with Zero Data Loss

Getting the site working on a staging URL is only half the job. The second half — switching the live domain, migrating the production database, and making sure nothing breaks during DNS propagation — is where most migrations run into unexpected problems. This article covers the go-live process for skylinerenting.eu, including the database cutover, DNS record update, an SSL issue that appeared mid-migration, and a Symfony cache problem that caused a brief outage.

Staging Confirmation Before Go-Live

Before touching the live domain, the site ran in full on the SiteGround staging URL (sky.sg-host.com) for approximately two weeks. During this period, the frontend, property search, multi-language navigation, and the backend admin panel were all verified to work correctly under PHP 7.4.33. The staging database contained a copy of the production data taken at the start of the project.

Only after the client confirmed the staging site was acceptable did we proceed with the domain switch.

Database Migration

The production database was exported from the old Combell server via phpMyAdmin and imported into a new database created on SiteGround. The database connection settings in Symfony live in config/databases.yml — this file was updated with the new SiteGround database name, username, and password before the domain went live.

No data transformation was required. Doctrine 1.x schema was compatible between the two environments, and all property listings, images, and user accounts transferred cleanly.

DNS Cutover

The domain skylinerenting.eu was registered and DNS-managed through Combell. The client needed to provide access to the domain DNS panel — the person with those credentials was on vacation, which caused a two-week delay between staging completion and go-live.

When access was finally provided, the A record for skylinerenting.eu was updated to point at the SiteGround server IP. Several DNS records were deliberately left unchanged — the domain had a separate email infrastructure (Mailtrap) with its own MX, SPF, DKIM, and DMARC records, and touching those would have broken the client’s email delivery.

The records left unchanged were:

• A record: app.skylinerenting.eu
• CNAME and TXT records for Mailtrap SMTP
• DKIM records (rwmt1, rwmt2)
• DMARC TXT record
• CNAME: mt-link.skylinerenting.eu

SSL Configuration

SiteGround provisions Let’s Encrypt SSL certificates automatically when a domain is pointed at its servers, but the certificate issuance requires the domain to be resolving correctly first. During the propagation window — before the DNS had fully updated worldwide — the site was temporarily unreachable, which is expected. Once propagation completed, the SSL certificate was issued and HTTPS worked without any manual configuration.

An nginx error log entry appeared during the propagation window referencing a missing .well-known/apple-app-site-association file. This was not caused by the migration — it was a routine bot request that happened to hit the server while the site was still being set up, and it had no effect on the site itself.

Symfony Cache Issue During Go-Live

Shortly after the DNS update, the live site returned errors. The staging environment had been working correctly, but the production domain was not. The issue turned out to be Symfony’s compiled configuration cache — the cache files had been generated with paths and settings referencing the staging URL (sky.sg-host.com), and after the domain change, some of those cached values were stale.

Clearing the cache resolved it:

rm -rf cache/*
chmod -R 777 cache/ log/

This required logging into SiteGround to run the command, which needed an authentication code from the account owner. Once the cache was cleared and Symfony rebuilt its configuration for the live domain, the site loaded correctly. Total downtime from the DNS update to full resolution was under two hours.

Final State

The migration was complete by the morning of 19 December 2025. The live site at skylinerenting.eu runs on SiteGround under PHP 7.4.33, with all frontend and backend functionality intact. The client’s email infrastructure was not disrupted. No data was lost in the database migration.

The key lesson from this project: legacy Symfony 1.x applications are migratable to modern hosting without a full rewrite, but the process requires careful version selection, targeted vendor library updates, and a willingness to debug framework internals that have not been officially maintained in over a decade.