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 at 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 & Time Breakdown

▬ 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

Statistics

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

Result

Successful Fix

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.