Migrations

There are several good reasons for wanting to migrate your legacy web system – for example to:

  • mitigate current hardware limitations
  • facilitate more efficient sharing of resources with other systems
  • cut costs by shifting to a cheaper service provider
  • move away from deprecated platform software
  • take advantage of cloud architecture

Recent advancements have made migration relatively straightforward for most systems developed today. In contrast legacy systems may not have been written with portability and platform-independence in mind – which means getting them to play ball on new hardware can be much more of a challenge. That’s where our solid experience in migrating legacy systems can come to the rescue. We can take away the headache and get your new deployment up and running quicky, leaving you free to focus on moving your business forward.

Migration to a standalone target machine

You may want to undertake this kind of migration if your current system is suffering from low remaining disk space, insufficient bandwidth or poor connectivity, or you want to benefit from more modern hardware (e.g. SSD). Migration to a standalone target is usually the simplest because the new deployment is unlikely to clash with existing processes. However some common challenges that may still need addressing are:

  • IP addresses, paths and URLs may need to be changed throughout the code (and may be hardcoded)
  • The relevant system users and resource permissions need to be set up identically on the target machine
  • it may not be possible or desirable to use the original operating system, database software, language version or other third party software
  • separation of code may be necessary if the source machine hosts more than one system

Migration to a standalone target machine can often be done quickly and painlessly, and is usually inexpensive. Get in touch with us via email ( ) to get a free evaluation of your own situation, and a cost estimate.

Case Study: Migration of Python 2.6-based Antiques Auction Web-Application

Developer Evaluation

Substantial code-base incorporates some complexity and a variety of coding styles – mainly due to the number of years of operation… Hardcoding appears minimal in packages, which generally refer to config files. However hard-coding is widely prevalent in the older scripts, and this is likely to be the main issue which needs addressing, particularly as the new setup will be accessed directly rather than via a network… [Migration] should be straightforward as the client does not require the OS or other components to be upgraded…

Steps Taken

  • created db dump and backup locally alongside all files (original backup)
  • committed code on source to fresh git repo
  • pulled repo locally (first git version backup)
  • Set up OS, installed Apache 2.0 and MySQL 5.0 on target
  • Created MySQL db from dump, set up db users + permissions
  • Pulled repo onto target
  • Configured Apache, iptables, file permissions to get working httpd instance
  • made code changes (config + hardcoding) to enable normal operation
  • ran tests

Time Breakdown

Statistics

  • Manpower:
    1 Developer + 1 Supervisor
  • Time to Completion:
    1 working day
  • Server Downtime:
    None
  • Total Developer Hours:
    9
  • Cost Per Hour:
    $45
  • Total Migration Cost:
    $405

Result

Successful
Migration

Uniting Separate Systems on the Same Server

You may wish to do this to improve efficiency, if systems interact frequently – alternatively you may be conscious of unused disk space or bandwidth, and be aiming to reduce cost. Putting systems on the same server allows rapid, timeout-free interaction and can reduce overall disk usage through shared resources. However the more resources are shared, the more care needs to go into ensuring components cooperate smoothly. Typically uniting separate systems on the same server involves facing the same hurdles as migrating to a standalone machine, but with some additional challenges. Some examples are ensuring

  • the sum of maximum load, bandwidth and swap space for all systems is within tolerance
  • the maximum number of supported connections to databases and other services is scaled appropriately
  • simultaneous resource requests cannot cause bottlenecks or hung processes through locking
  • there are no collisions with IPs, paths, URLs, access routes, cache namespace etc.

Depending on your platform loads, uniting systems on the same server may be more complex to implement than deployment on fresh server space – however we have the expertise to deliver a solution safely, quickly and at minimum cost. To find out more about your own situation, email us at <> – and we will provide a free initial evaluation and cost estimate.

Operating System Change or other Software Migration

This is often more involved than a simple hardware migration, but there may be several legitimate reasons for implementing it. Some examples are:

  • difficulty in finding expertise and/or dwindling support for the older software
  • the need to upgrade software to see hardware benefits (e.g. 32 to 64 bit)
  • to consolidate with other systems and thus reduce overall software dependencies
  • to meet broader company policies or infrastructure requirements

Many real cases of hardware migration also involve some elements of software migration, as it is not always possible or desirable to keep source and target software identical. The greater the change in underlying software, the more complex the migration may be. It is worth pointing out that this can still apply with systems that have been built with tools that are theoretically platform independent (e.g. Java). If you are considering a migration involving a significant software change, then we can help. Send us an email at <> detailing your situation, and let us get back to you with a free initial evaluation and cost estimate.

Case Study: Migration of Perl-based payment service portal from 32bit -> 64 bit OS

Developer Evaluation

[This is a] concise REST based payment service interface for a larger e-commerce site, operating as a pair of Perl-Catalyst applications… The service routes payment requests to various payment gateways based on settings controlled via a basic web GUI. The REST payment application is more extensive but is written in a single language and is reasonably consistent… It’s unlikely there will be an issue moving from Perl 5.10 to 5.18. The client has expressed a desire to integrate the few remaining CGI scripts into the main Catalyst application as part of the migration process. This looks to be mostly a matter of moving script subs into modules, but it is advised that the existing test framework be extended to cover the new code. Ubuntu server 14.04 ships with Apache 2.4 as standard, so Apache config files will also need manually going through and updating as 2.4 is not completely compatible with 2.2.

Steps Taken

  • created db dump and backup locally alongside all files (original backup)
  • cloned subversion repo with git-svn and pushed to new git repo
  • pulled git repo locally (first git version backup)
  • Installed Ubuntu Server 14.04 via VPS web interface
  • Installed Apache 2.4, PostgreSQL 9.3, Catalyst + required Perl modules
  • Set up users/permissions on Postgres, iptables + file permissions
  • Pulled git repo onto target
  • Converted apache2.conf to valid Apache 2.4 format + started apache
  • Refactored CGI scripts into Catalyst modules
  • Added unit tests
  • Ran tests

Time Breakdown

Statistics

  • Manpower:
    3 Developers + 1 Supervisor
  • Time to Completion:
    2 working days
  • Server Downtime:
    None
  • Total Developer Hours:
    36
  • Cost Per Hour:
    $45
  • Total Migration Cost:
    $1620

Result

Successful
Migration