How to plan an infrastructure migration before end of support

What this AWS migration teaches us

The source article starts from a very specific case: some AWS Storage Gateway appliances built on Amazon Linux 2 must move to Amazon Linux 2023 before standard support ends, and there is no in place upgrade path. Beyond AWS, the lesson applies to any VPS admin, dedicated server owner, or hybrid infrastructure team. When the underlying platform reaches end of support, delaying the work increases exposure to security issues, compatibility problems, and rushed changes under pressure. The safer model is disciplined replacement: provision a new instance, move the required resources in a controlled way, preserve service identity where possible, and automate repeated steps.

Practical checklist before the maintenance window

• Build a clean inventory of affected systems: OS version, server role, applications, data volumes, IPs, DNS records, certificates, and external dependencies.
• Confirm that backups are both recent and restorable, not just present in a panel. For typical hosted websites, verify web files, databases, and email data separately.
• Stop write activity before migration. On WordPress, enable maintenance mode and pause cron driven imports, sync jobs, or scheduled tasks during the window.
• Check whether services are reached by DNS name or by direct IP. If shares, apps, or webhooks still use the old IP, migration will create avoidable disruption.
• Prepare automation for provisioning and execution. The source uses Terraform and Ansible, but the key operational point is to separate infrastructure creation from the actual cutover steps.
• Write down a rollback plan in plain steps: what to restart, which volume to reattach, which DNS record to revert, and who approves the rollback.

What a hosting customer or admin should check in real life

For MioriticHost readers, the practical takeaway is that migration is not only about booting a new machine. You also need to check everything around it that can fail. If your site runs on cPanel or Plesk style hosting, lower DNS TTL about a day in advance so an IP switch propagates faster. If email is on the same server, verify MX, SPF, DKIM, and make sure the new IP is not blocked by firewall rules or rate limits. For web apps, prepare a short post migration test list: admin login, form submission, database connectivity, cron jobs, caching, SSL, and outbound email delivery. One very practical recommendation is to save Apache or Nginx configs, virtual host files, and active PHP versions before the change, because many post migration issues come from small configuration differences rather than lost data. A second concrete recommendation is to keep a written list of mount points, attached volumes, UID mappings, and permissions for critical directories, especially for apps that write to storage, uploads, or local backups.

The safest migration is the one where you change as little as possible at the same time: infrastructure first, service validation immediately after, optimization only at the end.