Migrate from AWS to On-Premises

In this article

• Define On-Premises (aka On-Prem)
• Prepare Your On-Premises Cloud
• Final Thoughts

Define On-Premises (aka On-Prem)

First, what does on premises mean? The term on-premises or on-prem has morphed in the last 10 years.

Let’s start out with the old school definition then talk about the more typical meaning in 2023/2024. Keep in mind the old school definition is not really done that much anymore and when it is, the company doing it is either very large or the company is a hosting, SaaS, or cloud business themselves. (The 2014 version is “ish” as this is something that has been changing and I’ll see about finding an actual tipping point.)

For those of you thinking that the new school is just colocation I would say yes, and I wished people would just let go of the idea of migrating from AWS to on-prem when they are actually talking about colocation.

On-Premises for 2000 to 2014 (Old School) –
In your data center that you built, with servers you bought/leased. Power, cooling, and hardware taken care of by your staff and 3rd party experts in your building each day.

On-Premises for 2015 to today (aka Colocation) –
In a colocation cage from a data center provider, with hardware you bought/leased, with visits from your direct staff, third party experts, and help from DC “smart hands”.

For those of you who use colocation, particularly in large markets like Ashburn, Virginia or Dallas, Texas, this doesn’t require explaining. You have walked past cage after cage after cage within a cavernous dark industrial scale data center. It is clear this is what is happening.

To help understand options available when migrating from AWS to on-premises and other clouds it is good to understand the modern Cloud Deployment options.

See Cloud Deployment Models

Prepare Your On-Premises Cloud

Since for both on-premises and colocation you have bought or leased your own servers, you now need to make those servers ready to migrate a cloud workload from AWS to your servers.  

1. At this point, we will assume you have your hardware in your data center and you have the networking for IPMI, for the “front LAN”, and for the “back LAN” already configured.  A note – we highly recommend using the minimum number of switches with good VLANs for all this and not a bunch of separate switches unless you have a scale that allows for this without wasting a bunch of your on-premises dollars.  Front and Back LANs are also something you may not want to do anymore. We typically don’t as it creates what turns out to be an artificial bottleneck.
2. Next automate you hardware management with things like IPMI, PXE booting, OpenStack Ironic or just manually setup the hardware that was not worth automating.
3. Next you turn the hardware into a cloud with systems like OpenStack, Ceph, Minio, CloudStack, MaaS, VMWare, Nutanix, OpenShift/OKD, Rancher and Longhorn, etc.
4. All modern systems have decent APIs – we recommend OpenStack ourselves of course – but after above you will have a set of APIs or GUIs for self service resource deployment and for migration systems to talk to when automating the moves.

If that is more than what you are up for or don’t have the time, we recommend moving your AWS workloads to a hosted private cloud. If you are going down this path we encourage you to still use OpenStack and check out our How to Build a Private Cloud on OpenStack article.

Migrate from AWS to OpenStack

Since we know OpenStack the best and help customers move from AWS to OpenStack here is a useful chart showing the services between the two cloud systems.  Other major cloud systems all cover the most popular services and we have pages on those versus OpenStack.