AWS Migration Considerations Series: Pre-Cloud Migrations

 

Unlocking the power of AWS: A comprehensive guide to Cloud migrations

Since 2013, Akkodis has migrated many client workloads into the AWS cloud. These workloads have been migrated from existing data center co-location, customer data centers, Microsoft Azure, Google Services, and more.

The workloads have been a mix of technologies in the stack: Java, .Net, Python, and NodeJS, and databases from Oracle, SQL Server, Postgres, and MySQL. They have been in several customer verticals, from start-ups to large enterprises and government.

In this series, we will look at the following topics:

Part 1: Pre-Cloud Migrations: Migrations before the Revolution of AWS

Part 2: Why Migrate to the Cloud

Part 3: Ongoing Migrations within the Cloud

Part 4: Migration Methodologies: Migration Pattern for Workloads to AWS Cloud

Part 5: The Roadmap: Migration Pattern for Workloads to AWS Cloud

Part 6: Financial Considerations: Cost of AWS & Management Model Costs 

Part 7: Governance & Security: Lift Your Security Posture without Replicating the Past

Part 8: Move to Managed: Leveraging AWS Platform Services versus Roll-Your-Own

Why an organization would do any form of migration?

Digital system migrations have been happening since the dawn of digital services. Every digital service that has endured more than a couple of years has generally had a migration of some sort. They have been called other things, but servers, storage, and even data centers have been swapped to new solutions.

The equipment in a data center was often commissioned and used right up until a few months before the expiry of the IT equipment warranty or the equipment lease expiry.

The process would start a year from the proposed end date, with fresh equipment being reviewed and priced. Data center visits would then be undertaken to inspect the new building (or new space in the existing facility to set up while the existing systems are still in use). 

And then a synchronized dance would happen:

• Order new data center space with a nominated start date, around 2-3 months before the expiry of the old. Your costs have started before the space is generating any revenue. $+
• Order the new hardware, with a delivery date just after the proposed start date of the new facility. Pay for the equipment (or start a new lease) before the equipment generates any revenue again. $+
• Modify DNS TTLs to a suitable low value (because historically, this was set to days or weeks).
• Wait until new equipment is delivered.
• Madly rack & stack, image systems, and extend networks to the new site.
• Copy data – in one of several ways from old environment to new.
• Schedule downtime on the old equipment, one more copy of data, and then update DNS to point to new IPs and go live.
• Decommission old systems. Un-rack and return/sell. From this point, we’re stopping the double-bubble of twice the costs. $-
• Give notice on the old facility. $-

Strategic planning and execution: Navigating data center transitions

We started paying for the new data center and the kit well before the cutover. Even without a data center change, there is the risk of doing something like a Storage Access Network (SAN) migration:

1. Observe new SAN is coming to end of life or warranty renewal is becoming prohibitively expensive.
2. Determine new SAN equipment to move to (over weeks of research time).
3. Determine insufficient rack space in the current rack to install the replacement, so obtain an additional rack near the existing servers. $+
4. Order new SAN. $+
5. Wait for the new SAN to be deployed.
6. Rack & stack new SAN.
7. Determine the data migration plan.
8. Connect existing servers to new SAN (if there are enough fiber ports).
9. Downtime on your services, move final data, remount file systems, restart service.
10. Disconnect servers from old SAN
11. Dispose of old SAN.
12. Try to offload the now empty rack in the middle of your contiguous block of cabinets, but find that no one wants just one rack in the middle of your sequential block of cabinets.

Managing the hidden costs of technical maintenance

Depending on the installation size, all that work required a team to do the job. The cost of these team members to do this work, as well as the double-bubble cost of having new equipment while not yet using it and old equipment that is no longer in use but not yet sold, represents a massive cost of operation.

You will likely find that just because you have replaced a SAN does not make people use your service or buy your product anymore; it is not a key differentiator in your market. We are trying to maintain the technical environment—to maintain what we already have.

These migrations within deployed solutions are continuous. Operating Systems, Hardware, Programming languages (yes, your Java and .Net and Python and everything else needs updating), Data Centres, Telcos & Internet Service Providers, DNS registries, CDN operators, database versions (and database types/engines); the list goes on for the maintenance that is often overlooked or accumulating as Technical debt.

Finally, as much as we have spoken about migrations in a pre-cloud world, it is worth asking another question: When you get to the Cloud, do you still have these hidden migrations? Stay tuned to our next few issues to find out.

Akkodis has been an AWS Consulting Partner since 2013. Learn more about our AWS Practice and services.

By James Bromberger, VP Cloud Computing, Akkodis Australia