Every migration looks simple on paper. Move the app, move the database<\/strong><\/a>, point the DNS, done. Then you flip the switch and something you never even knew existed stops working. A cron job that nobody documented. A hardcoded IP buried in a config file from three years ago. A firewall rule that was quietly doing more than anyone realized.<\/p>\n If you have ever moved a server from one platform to another, you already know the real work isn’t the move itself. It’s finding everything the application depends on before you move it. That’s what a proper pre-migration assessment is for, and it’s the difference between a clean cutover and a weekend spent firefighting. The good news is that a new platform giving you clearer, more explicit control over these pieces makes them easier to find, document, and manage for the long run, but it does mean doing that discovery work upfront instead of relying on things happening automatically in the background.<\/p>\n Here’s what actually needs checking before you touch anything.<\/p>\n Before you migrate a single file, you need to understand what you’re actually dealing with. Is this a single monolithic app, or is it split across multiple services talking to each other? Is there a load balancer in front of it? Does one server depend on another server that isn’t obvious from the outside?<\/p>\n This matters because the old platform may have been handling connections between these pieces automatically, in the background, without much visibility into how. A new platform typically asks you to define these relationships explicitly, which takes a bit more upfront mapping but leaves you with a much clearer picture of your own architecture going forward. A five-node stack with a load balancer, an app server, a database primary and secondary, and a caching layer all needs to move together, in the right order, or things quietly break in the middle.<\/p>\n Draw it out if you have to. A rough diagram of what talks to what saves hours later, and it’s a document you’ll actually be glad to have on the new platform.<\/p>\n Database migrations look deceptively easy until you actually run them. Connection strings often point to internal hostnames or IPs that won’t exist on the new platform. Character sets and collations can differ between environments and cause silent data corruption. Locale settings, especially with PostgreSQL, can throw errors that have nothing to do with the actual data.<\/p>\n Also check for anything unusual in the schema. Custom stored procedures, triggers, replication setups, or even a single missing column that an older app version depended on can take down a service after everything else looks fine. Always verify data integrity after the move, not just that the restore “completed successfully.”<\/p>\n If the app runs in Docker or a similar container setup, don’t assume the container is self-contained just because it’s a container. Environment variables, volume mounts, and network configurations inside a docker-compose file are often tied to assumptions about the old environment.<\/p>\n A common one: the app was working fine, but the binary or dependency was present on the new node while the runtime environment variables and encryption keys were not. Everything looks installed, nothing actually works. Check every environment file the container reads from, not just the obvious one.<\/p>\n Environment variables are where old platforms tend to bury their fingerprints. Database hosts, API keys, internal service URLs, feature flags, all of it usually lives here. The problem is that these variables often get set once, work for years, and nobody remembers where they are or what depends on them.<\/p>\n Go through every .env file, every systemd service definition, every supervisor config. If a variable references an internal IP, a hostname specific to the old platform, or a path that won’t exist after the move, note it down now. Cataloguing these once, at migration time, is also a good opportunity to clean up years of undocumented sprawl and start the new environment with a tidier, better-understood configuration.<\/p>\n This one deserves its own section because it causes more post-migration outages than almost anything else. Internal IP addresses change between platforms, always. What doesn’t always change is every place in the app that references them.<\/p>\n DNS resolvers pointing to internal servers that no longer exist. Database connection strings using the old private IP. NFS exports referencing the old network range. Load balancer upstream configs pointing at an IP that belonged to the previous platform’s internal network. These don’t throw obvious errors, they just make things slow, or make things fail intermittently, which is worse because it’s harder to diagnose.<\/p>\n Search the entire codebase and every config file for the old internal IP range before migration, not after something breaks.<\/p>\n Check what’s mounted where, and how. NFS exports, shared volumes, and network storage often reference the old platform’s internal addressing or hostnames. A mount that worked fine before can silently fail to attach on the new platform, and depending on the app, that might not throw an error immediately. It might just mean files stop saving somewhere nobody checks regularly.<\/p>\n Also worth checking: file permissions and ownership. Some migration tools strip execute bits or change ownership during the copy, which causes scripts to silently fail to run even though the files are all there.<\/p>\n Here’s something that trips up almost every migration at some point. The old platform handled basic connectivity automatically, things like open ports for web traffic and automatic routing between internal services. The new platform takes a different approach: it gives you explicit, granular control over networking, which means these things need to be configured intentionally rather than happening by default. That trade-off is worth it, it means nothing is open that you didn’t choose to open, and your network posture is something you can actually audit rather than inherit blindly.<\/p>\n Port Forwarding for Application Ports<\/b><\/p>\n On the old platform, port rules were often created automatically as part of its built-in automation. This felt convenient at the time, but it also meant firewall rules were opened without anyone explicitly reviewing or approving them, so it was common to end up with ports allowed that nobody remembered enabling or even needed anymore. Over time, this quietly increases the attack surface, since unused or forgotten open ports are exactly what a security audit, or an attacker,<\/b> looks for.<\/p>\n On our new AWC platform, it takes a different approach: nothing is opened by default. Port forwarding for 80 and 443 has to be explicitly configured, and any custom ports the application uses need their own rules. If there’s an admin panel, an API, or a webhook endpoint on a non-standard port, it needs to be accounted for individually.<\/p>\n This is one of the most common gaps in a migration checklist, and it’s an easy one to miss, not because our new platform is lacking, but because the old platform’s automation meant nobody ever had to think about it before. The upside is that once it’s mapped out, you end up with a firewall configuration that’s minimal, fully documented, and fully in your control, with every open port tied to a known, intentional purpose rather than a default nobody questioned.<\/p>\n Cron jobs and scheduled tasks are notorious for being invisible until they fail. Check every crontab, every scheduled task, every background worker. What are they doing, when do they run, and what do they depend on?<\/p>\n A job that backs up a database at 2 am, a script that clears old logs, a task that syncs data with a third party. If these reference paths, IPs, or credentials are tied to the old environment, they will fail quietly, and you might not notice for days, until the disk fills up or the backups<\/strong><\/a> stop appearing.<\/p>\n Does the app call out to any external services? Payment gateways, email delivery services, authentication providers, SMS APIs? Many of these validate the calling server in some way, sometimes by IP allowlist, sometimes by domain.<\/p>\n A particularly common consideration is authentication providers that reject IP-based redirect URIs entirely. If the app uses something like Azure AD B2C for login, full auth testing often can’t be completed until DNS is actually pointed at the new server, since the provider won’t accept a raw IP as a valid callback address. Know this ahead of time so it doesn’t look like a broken migration when it’s really just an expected step waiting on DNS cutover.<\/p>\nStart With the Application Architecture<\/b><\/h2>\n
Databases Are Never Just “Copy and Restore”<\/b><\/h3>\n
Containers Bring Their Own Baggage<\/b><\/h3>\n
Environment Variables Hide More Than You Think<\/b><\/h3>\n
Internal IPs Are the Number One Silent Killer<\/b><\/h3>\n
Mounted Storage and File Paths<\/b><\/h3>\n
Firewall Rules Nobody Wrote Down<\/b><\/h3>\n
Scheduled Jobs Don’t Announce Themselves<\/b><\/h3>\n
Third-Party APIs and Outbound Dependencies<\/b><\/h3>\n