Don’t Wait: Continuous Migration

Whether you are just moving to Drupal or upgrading to a new version of Drupal, if you are starting with an existing website, you are facing the same problem: Your migration timeline. It will take you significant effort to move everything you have to the new system and you cannot play catch-up all the time. That's why many people are opting for continuous migration. What does that mean? Run the migration project in parallel to your existing website effort and migrate gradually, page by page and URL by URL. New functionality is done in the new system, old functionality stays until it's time to move it.

Doing continuous migration will help you to:

• Reduce the risk of your migration by only putting one page on the new system first, ensure everything is working and then ramp up
• A/B test your old and new pages and make sure the new system is achieving the right conversion amounts
• Avoid the "shock effect" that might occur due to the scale of the change all at once. Its always best to prepare users and acclimate them to the change one at a time.

In this article, I'll show you the step-by-step solution to get requests to a single domain and route them to different backends based on the state of your migration.

All URLs have the same domain so your users will not see a change - this is a prerequisite for successful migration as you cannot create an old.example.com domain for SEO and search results continuity.

There are a number of ways you can tackle this requirement:

• If you are using Akamai, create a routing rule in their backend
• If you have your own Varnish cache, create a custom VCL and route requests there
• Using SaaS services

Most technical folks would naturally choose to create their own Varnish configuration but this approach forces you to do a new VCL deployment every time you change URLs and direct VCL configuration is sometimes not available to users. Let's take a look how to do something very similar but without messing with VCL configuration using a very neat service from our partner Fastly.com - essentially Varnish in the Cloud. They offer an advanced web UI for configuration and API if you want to automate all deployments.

This is how, the system will work:

• example.com will be pointed to Fastly CDN service
• request will arrive in ‘Fastly' and decision will be made on which backend should be serving the data and following which the request will be sent into the backend
• ‘Fastly' will cache the data as any other Varnish system

Let's look at a potential implementation for this requirement. First go to ‘fastly.com' and sign up for a free account. Once you get one, use the set up wizard to create a new Service and follow the steps below.

Step 1. Create the service

• Name it Dual backend test.
• Choose your current Server Address, let's say drupal.cz and drupal.cz as Domain Name.

Step 2. Edit host configuration

As a first step, we need to create a new Host as a backend for Fastly - this is our new Drupal 7 site. Click on Hosts, New and create it as following:

• Address: drupal-d7.org:80
• Name: drupal.org-d7
• Auto Load Balance: No

Step 3. Configure request headers

Once you have a new backend, we will configure request headers based on the conditions. As an example, we will want to redirect everything that starts with /user* to the new backend:
First, make sure Fastly switches between backends based on the request condition. Click on Content and create a new Header:

• Name: Backend-new
• Type/Action: Request, set
• Destination: backend
• Source: F_addr_drupal_org_d7
• Leave everything else as default.
• Notice: the Source is named according to your added Hosts - if we named a host drupal.org-d7, then Source is F_addr_drupal_org_d7. You can find out your exact Source names if you click on the VCL button at the top of the page, it will say something like backend F_addr_drupal_org {

Step 4. Edit request conditions

As a next step, click on the Backend-new and edit it's Request conditions. Add a new condition:

• Name: User pages
• Apply if: req.url ~ "^/user*"

This condition will make sure that whenever someone visits drupal.org/user then the new backend is used.

Step 5. Configure the domains

As a last step we need to set http.host for our backends otherwise your servers will not recognize the domains used for all requests. Again, create a new Content -> Header:

• Name: Set host to drupal-d7.org
• Type/Action: Request Set
• Destination: http.host
• Source: "drupal-d7.org"
• Notice: the quotes in your Source.

Once added, set a request condition for this header to the User Pages condition and create a second header Set host to drupal.org with similar settings:

• Name: Set host to drupal.org
• Type/Action: Request Set
• Destination: http.host
• Source: drupal.org
• Request condition: none

Step 6. Test Fastly request routing

As you deploy this configuration, Fastly will route requests between your backends:
If you go to drupal.org/node, your request will go to the drupal.org backend, if you go to drupal.org/user, your request will go to the drupal-d7.org backend and your users will not notice anything! Job done.

Reach out

If you ever did a project like this, let me know in comments or on my Twitter @jakubsuchy, I would love to see your ideas and experience. Our Professional Services team is routinely dealing with difficult migration projects so get in touch if you need help!