There are many reasons you might want or need to migrate from your current cloud provider to another cloud provider. It could be to save money, meet government/corporate security requirements, or simply to appease the higher-ups in the company. In any case, the process can be daunting.
What it Takes to Migrate
The typical site/web-application migration process can be... involved. From a high level, it requires the following (at the very least):
- Building the new infrastructure
- Architecting and building a code deployment strategy/process
- Migrating data
- Flipping the DNS switch to point to the new infrastructure
Building the Infrastructure
Building and configuring the new infrastructure is by far the most complex and time-intensive stage of migrating a web application to a new host. To start, you have to familiarize yourself with the intricacies of the host – everything from pricing and server provisioning to standards compliance and access control policies. Then comes the process of actually building the infrastructure:
- Provisioning and configuring server(s)
- Networking the infrastructure
- Securing the infrastructure with firewalls and access control protocols
We've seen this process take anywhere from a couple of days to even a couple of months, even for those who are intimately familiar with the process. It's not easy and can be a real time sink for your team. So much so that entire industries have been formed to simplify this process – IaaS, PaaS, DevOps, etc.
A Quick Note: The Burden on Developers
As the barrier-to-entry for cloud infrastructures has lowered over the years, it's made it possible for smaller teams to leverage the power of these types of infrastructures. However many teams simply can't afford engineers who specialize in infrastructure. Because of this, the burden of building and configuring infrastructure has been increasingly placed on developers.
In many cases, developers are expected to be infrastructure experts as well as write the application code. It's hard to do both.
Using Nanobox to Migrate
Nanobox was built based on lessons learned from nearly a decade of building high-available cloud infrastructures. We're intimately familiar with this process and how painful in can be.
Defining the Infrastructure in the Project
We've found the first step to easily migrating an app to a new host is defining the needs of the infrastructure and including that definition in the project. With Nanobox, this is done in the
Example boxfile.yml for a Simple LAMP stack
run.config: engine: php engine.config: runtime: php-7.0 document_root: public extensions: - pdo - pdo_mysql - mbstring - tokenizer - session - zip - dom - xml - ctype web.main: start: php-server network_dirs: data.storage: - public/uploads data.db: image: nanobox/mysql:5.6 data.storage: image: nanobox/unfs:0.9
This tells Nanobox the app needs a PHP runtime with PHP 7.0, provides a list of extensions that need to be installed and enabled, sets Apache's document root to the
public directory, and outlines the need for a web server, a MySQL database, and a persistent filesystem for uploads.
Automate the Build
Again, building and configuring the infrastructure is by far the most complex, time-intensive step of migrating a web application. Nanobox automates everything from ordering and configuring your servers to networking and access control. What normally takes days, weeks, or even months, is done in a few minutes.
With the infrastructure definition included in the project, on deploy, Nanobox provisions the entire infrastructure in a private network, builds and configures each of the components included in the
boxfile.yml, provides a load-balancer, aggregated logging, and server monitoring, all on your cloud provider of choice.
Developers no longer need to sink time into learning the intricate details of building and configuring a database or how to handle written files in a multi-node cluster. That burden of knowledge is borne by Nanobox.
Nanobox is built to be provider agnostic. While there are officially supported cloud provider integrations, there is an open specification for integrating with any provider with api-based server management.
Migrate Your Data
Migrating data can be scary, and we've found that it's a tricky balance between uptime, engineering expertise, and potential data loss.
Avoiding Data Loss
Any time you move data, there's and inherent risk of losing data. The best approach we've found that has the lowest technical requirements and prevents data loss does require some downtime.
The first thing to do is export your data from your current provider and import it into the database on your new provider. Your running app will continue to collect data, but the data snapshot will allow you to thoroughly test the new setup with real data.
Just before you switch your DNS, deploy a maintenance page to the old app to prevent any new data from being written, re-export the data to pull newly added data, then import the new data into your new database.
Switch Your DNS
Switching your DNS is a fairly simple process, but there's one thing that is incredibly important, but is often overlooked – turning down your domains' Time to Live (TTL).
Turn Down Your TTL
A domain's TTL defines how long routes are cached in nameservers and affects how quickly any changes propagate. Before making changes to your DNS record, you should always set your TTL as low as your DNS provider will allow.
Flip the Switch
Once everything is tested, deploy a maintenance page to the running site to prevent new data from being written. Export the final data dump, import it into the new site, then update the DNS record to point to the new infrastructure. As the DNS change propagates, routes to the maintenance page on the old infrastructure will be replaced with routes to the app running on the new infrastructure.
The Migration Process in a Nutshell
Nanobox simplifies the process of migrating a site between hosts by removing the need to fully understand the intricacies of a cloud provider's system, building and configuring the environment, then architecting and implementing a deployment strategy. This is what the migration process with Nanobox looks like in a nutshell:
- Pick a new cloud provider
- Add a
boxfile.ymlto the project
- Migrate your data
- Switch your DNS
This is Why We Built Nanobox
In our years of experience building and managing high-availability cloud apps, we found ourselves doing to the same things over and over. The seeds of Nanobox were planted as we began to automate the repetitive, tedious tasks. It has evolved into a micro-platform that builds your app anywhere.
Subscribe to Nanobox
Get the latest posts delivered right to your inbox