Changing hosting: plan data and cutover together
Plan the database, files and write access together. A worked sequence separates preparation, cutover and the rollback path once new changes exist.
A hosting change is complete for your team when the agreed workflow runs at the new location with the right data state. Decide in advance when changes will be accepted, who authorises cutover and under which conditions the team can return.
Identify the workflow and its write paths
In the fictional example, a company operates the customer portal P-65. A customer creates request A-65 with attachment F-65. The database and file store belong together. Besides the browser, an interface and a background process can change data. All these write paths must be included in the transition plan.
This example uses an announced pause in writes. That is a deliberate choice, not a requirement for every migration. The team finishes ongoing changes in a controlled way and records which open tasks may continue at the destination. Continuously transferring new changes would be a different method with its own synchronisation and conflict checks.
Agree the cutover as a sequence of work
AWS recommends documenting and rehearsing dependencies, task order, owners, checks and the rollback path before the change. The completed planning template below contains intended steps, not results of a migration that has been performed.
Phase | Agreement in the example | Responsible role | Condition for the next step |
|---|---|---|---|
Preparation | Check the destination environment with a consistent database and file copy. | Application team | Login and permitted access work, unauthorised access is denied, and the associated file opens in an isolated test. |
Write pause | Stop accepting and processing new changes at all old write paths; transfer the final consistent state. | Operations and application team | Open work is recorded; database and files match. |
Authorisation | Open the checked destination access point and accept changes only at the intended new write destination. | Business and operations owners | The authoritative data state, access route and stop decision are clear. |
Distinguish stopping and returning in advance
Microsoft recommends tailoring stop criteria and rehearsed return steps to the workload. In the example, a missing attachment already prevents authorisation. As long as no new changes have been accepted at the destination, a prepared rollback path to the unchanged old state may be suitable.
After new changes at the destination, resetting the DNS address is insufficient. Those changes may be missing from the old system. Returning then requires a defined authoritative data state and a tested method for the intervening changes. No uncoordinated parallel write paths are opened meanwhile. If the team cannot handle this case safely, it must change the transition plan before authorisation.
Complete DNS and the transition together
The DNS TTL describes normal caching of an answer. Some clients may therefore still use the old access point. Its behaviour must fit the write pause or the new authoritative system; two independently writable copies do not constitute a completed change.
Check the complete workflow in a suitable test environment, including a new request, attachment, roles and background work. External actions remain limited to test destinations there. Also plan monitoring and a responsible contact after authorisation. The old service is retired only once the agreed completion conditions and backup approach have been clarified.
Sources
Read more
All articles
Cloud & Operations with ASES
Hosting, deployment, maintenance and support