Scenario #17: Heave Ho - Take
Hi everyone!
Last week I asked about a small re-platforming exercise with a recently acquired company’s smallish stack running on a cloud provider that isn’t your preferred/main one.
What are your options, up-front, and recurring costs?
Option 1: Maintain the status quo
Nobody said you had to move it off the provider. Especially since this is a full acquisition. (TD’s note: if you acquired a divested business, then you really won’t have a choice here).
The only up-front cost here would be the config updates to reflect your company’s public internet presence and possibly tie in SaaS based services for it to phone home. From a risk perspective, you are effectively maintaining the status quo so you won’t need to worry about the apps going down or having a negative customer impact.
In this configuration, it is effectively air-gapped from your corporate network, which does have its own pros and cons. Mainly from a maintenance and support perspective. Your team will now need to be provisioned access to ensure proper care and feeding, and they’ll need to build out the infrastructure that already exists with your other systems.
If there is a need to migrate the data onto your corporate environment, then you may need to provision VPN access to bridge between the two ecosystems (your up-front cost and the recurring networking/VM costs to maintain it).
Going forward, you will be maintaining not just the monthly costs for the servers in the other cloud, but now your team will have to split time between your current ecosystem and this new one-off stack. It can be mitigated somewhat if you’ve retained the developers and admins from the old company.
Option 2: Move the systems
Another option is to power off the VMs and transfer them into your cloud provider. You will still need to reconfigure the underlying VMs to point to the resources on your network, and you can still keep them isolated in their own network segment.
The recurring costs would be the same as if you just added the new VMs directly. The up-front costs would consist mainly of the data transfer fees to copy the images and data into your provider. The only real upfront costs would be the data transfer fees to copy the VMs into your network. Granted I’m assuming there will still be the people required to handle the bring-up and troubleshooting.
The downtime would be the longest in this scenario as transferring full VMs is quite large and time consuming. This can be mitigated somewhat by taking and copying a full backup of the servers. Then perform an incremental backup/restore once the systems have been migrated and you’re ready to cutover.
The risk level increases from the first option due to baked-in assumptions about the environment the servers were running in such as networking details.
This will save you time compared to…
Option 3: Move the apps
The last option of moving the apps and data into new VMs running inside your environment. These will be machines provisioned and maintained using your standards. Cost-wise, these are known costs based on what you already have, The up-front costs from a cloud standpoint would still be the data transfer fees, but it will be limited to the application and the underlying data.
The downtime can be minimized even further based on when you bring up each component and get ready to handle the cutover.
The challenge and risk comes with ensuring you have all of the application components and dependencies migrated over and have a clean copy of the data.
With additional review, planning, and prep, you can fully integrate this app into your pre-existing ecosystem leveraging the hardware you already have and minimize your spend even more.
In short:
- Option 1 - Fastest and least risk, but comes with the greater recurring costs due to maintenance and non-standard configuration.
- Option 2 - Moderate benefits/risk (also only fallback if option 1 is unavailable).
- Option 3 - Slowest with moderate risk, but cheaper to maintain and offers additional benefits with a tighter integration to the rest of your ecosystem.
What do you think?
cab