For a large information website, copying the files and database is only part of a migration. The new environment must also reproduce the server configuration, certificates, scheduled tasks and behaviour of domains used by integrations. In this project, we prepared a standby environment for a substantial public-sector information website, together with a mechanism to update it overnight. The work formed part of disaster recovery (DR): restoring the service after a major failure.
The disaster recovery goal: a working copy and a repeatable recovery process
The task involved transferring the website to a failover environment that could be checked before a potential traffic switch. The production system remained the source of data. Scheduled synchronisation would reproduce its state on the standby server.
At the stage described here, we launched and tested the copy on a network accessible through a VPN. Public traffic had not yet been switched to the new infrastructure. This distinction matters: a working standby server provides a foundation for a recovery plan, while readiness to switch also depends on checking every dependency.
The scale of the project
The database contained 85 tables and approximately 3.42 GB of data and indexes after import. The SQL dump was approximately 2.18 GiB before compression. During copying, the file tree grew to more than 200,000 entries. The library of materials published on the website accounted for a substantial part of the transfer.
The first full synchronisation, including the uploaded media directory, took approximately 6 hours and 7 minutes. Subsequent verified incremental runs took 6 minutes and 58 seconds, and 6 minutes and 38 seconds. These measurements come from this deployment and depend on the volume of changes and transfer conditions.
Application code first, then the large media library
The full file transfer was taking long enough to delay application testing. We introduced a separate synchronisation mode that excluded the uploaded media library. This allowed us to complete the application code transfer sooner and test the website. The full mode still included the media library and was used for the overnight run.
During the transfer, the incomplete application returned errors. Investigation showed that some required WordPress files had not yet arrived. Once the faster run finished, the HTTPS test over the intended network path returned a successful response. Checking the cause prevented us from changing application code to address an error caused by an ongoing transfer.
Configuration matters as much as data
We transferred the nginx configuration, HTTPS setup and application tasks. The new environment used PHP 8.4, so the configuration needed to point to the appropriate PHP process. We also updated deprecated HTTP/2 configuration syntax. We checked the changes with configuration tests and website responses.
A domain used by the payment integration required particular attention. We added it explicitly to the configuration, verified the certificate and compared request behaviour with production. This comparison is useful, but it does not replace an end-to-end test of a real payment callback.
A further audit identified additional access-control and source-address configuration files, along with a technical virtual host, that needed to be included. DNS alias completeness also needed to be checked with the DNS provider. This illustrates why a migration project should have a separate list of dependencies to verify before switching traffic.
Overnight synchronisation and result checks
Full synchronisation was scheduled daily at 02:30 in the Europe/Warsaw time zone. It covers application files, the media library, the database and SSL materials. We excluded old server logs from the transfer. The subsequent runs we verified completed successfully, and checks confirmed the database import, 85 tables and a matching certificate and key.
We also tested access from Windows through the VPN, the HTTP-to-HTTPS redirect and the required services. The website copy responded correctly over that route. A separate configuration branch used by local requests still required further verification.
The overnight copy reflects the state of the last successful run. Content added afterwards reaches the standby server during the next synchronisation. The recovery plan needs to account for this model, with a synchronisation frequency suited to the institution’s needs.
The result and the next stage
The outcome of this stage was a working copy of the large website in a separate environment, together with a verified mechanism for keeping it updated. The initial transfer, which took several hours, gave way to short incremental runs. We also produced recovery scripts and documented the checks.
Before the entire environment can be considered ready for a traffic switch, the configuration and dependencies identified in the audit need to be completed, and DNS and real integrations verified. This case study therefore describes preparing a failover environment as part of disaster recovery, rather than a completed production migration or automatic failover.
Planning a migration or disaster recovery?
Talk to Projectic about migrating a large website, preparing a standby server or organising your disaster recovery process. We can help define the scope, identify dependencies and plan recovery tests before switching traffic.