Migrating Websites & Services Checklist

In: General

22 Jun 2009

I have been migrating a large number of websites and consolidating servers to reduce costs.
As a result it is important to ensure that services are migrated smoothly, planned effectively,
after which I had a think about aspects to consider prior to migrating services.

Planning

  • Make a preliminary checklist of services actively in use by each active domain, I.e. FTP, HTTP, SMTP, IMAP, POP3, MySQL etc.
  • What maintenance periods do you have available, if at all?
    • What volume of traffic and when are your quietest periods?
  • Do you have dedicated infrastructure, sharded, split by service/role?
    • Can parts of the infrastructure be migrated as an individual component
  • List core functionality from the domain for testing purposes
    • Ideally this should be wrapped in unit tests as both functional
      • Examples are email, upload (permissions), adding/editing/removing users
  • How many servers are you migrating?
    • Large quantities should be automated.
  • How critical is the site/service
    • Does it stop 80 staff working?

Specific

  • Services
    • Ensure services are initially installed on new server(s).
    • List all configuration files for a particular service (tree).
      • Ensure configuration between each service are identical or compromises are made.
    • List data directories for each service I.e. /var/lib/mysql
      • Can data be transferred automically.
      • Can services be replicated and brought into sync
      • Can data be back filled?
        • I.e Are large log tables required to make the site functional, what is the minimal effort required to bring the site functional?
  • SSL
    • Ensure valid certificate exists for any CDN, sub-domain, domain.
  • Email
    • Are there any special firewall, configuration requirements?
  • DNS
    • Lower the TTL for a domain your preparing to transfer (if possible)
      • Cannot rely on low TTLs, these are cached amongst large corporates, ISPs etc.
    • Ensure the domain is bound to a unique VIP on new servers, if DNS resolution fails, you can put a header(‘Location 10.10.10.10′); in the old site to ensure the domain will resolve correctly.
      • Test this prior to transfer for both HTTP & HTTPS if applicable
  • Permissions
    • Do you upload content to the servers, does your code write to the filesystem?
      • Is this writtable?
    • Under which user/group is this written?
  • Cache
    • Does your site make use of distributed or local cache?
      • Could there be collisions between different sites, I.e. Do you prefix cache key names based on site?
  • Networking
    • Can specific services be migrated prematurely?
      • Repoint via iptables, and keep an eye on bytes passing through the interface till redundant
  • Security
    • Were there any firewall restrictions that need to be replicated, either hardware, iptables etc.
    • Chrooted, users copied, ssh keys copied.
  • Optimizations
    • Were there any special optimizations, I.e. DnsMasq?, sysctl changes?
  • Load balancing
    • Ensure each domain has its own VIP – HTTP_HOST fails in HTTP 1.0 clients
    • Ensure wild cards are not specified within virtual hosts – see above
    • Ensure sites with load balancing and over SSL use TCP requests correctly, in addition see first point.
    • ifdown each VIP in the webserver pool, does it failover with the correct site on all nodes?
  • Monitoring
    • If previously had monitoring on servers (should do), has this been replicated to new servers?
  • Database (Will vary depending on setup)
    • Is the database replicated?
      • Take LVM snapshots of the raw data on slave and rsync to new servers.
        • Ensure to change configuration such as server id’s, permissions on master, firewall, start service and start replication. Will be ready to start replicating with correct binlog positions etc.
  • Other general changes
    • Are there customizations to /etc/hosts get sites working?

Let me know if there is anything you think I have missed.

Comment Form

About this blog

I have been a developer for roughly 10 years and have worked with an extensive range of technologies. Whilst working for relatively small companies, I have worked with all aspects of the development life cycle, which has given me a broad and in-depth experience.