Organizations that host large, integrated systems in their own data centres will no doubt be approached by their application vendors for migration to the silver lining of the cloud.

I was recently involved with appraising the feasibility of moving one of the largest Oracle eBusiness suite installations in the UK to “on-demand.” This experience gave me some insights into the complexities behind such a move.

Existing investment

In order to run very large applications with thousands of users, a substantial investment would have been made in existing infrastructure. This includes resilient server infrastructure, disk space, and software licenses.

You’ll need to spend some time considering what happens to this equipment if you migrate an application into the cloud, particularly as there may be other applications sharing processing power, shared disk resources and expensive database licenses.

If you move one of your applications away, you may have to migrate some or all of your existing licenses across to your provider, which could mean paying twice if there are multiple applications from different vendors hosted on the same platform.

Ancillary applications

Most big systems don’t work alone; you may have ancillary applications from different vendors for the purposes of enhanced reporting and data import.

So if you’re moving an app into the cloud, can provisions be made to give these interfacing applications the connectivity they need? Remember that many data transfers can take place in the night, which may be the time when a cloud provider needs to do maintenance.

There may be several suppliers involved in the running and support of an application suite. It’s worth checking if they have the support access they need, as specified in any existing contracts.

“PaaS” versus “SaaS”

For very large systems, you may have a choice of going for a “software as a service” (SaaS) or Platform as a Service (PaaS) option. Consider the impact of staffing changes.

Your organization may employ application experts, database administrators and staff to manage operating systems, servers and backup. These staff may not be needed if these systems are managed in the future by a supplier as part of a SaaS migration. Many countries protect employees with Transfer of Undertakings (TUPE) regulations. This would have negative consequences for employers if technical staff could not be redeployed elsewhere in the organization.

Disk space, growth and multiple instances

Testing and training instances of applications can grow over time and may be called “LIVE”, “DEV”, “TRAIN” or “TEST”. For an organization that owns their own kit, these instances are very easy to set up and are very useful for the testing of major application’s release and patching cycle.

Business folk may have access to these instances to run training sessions and to sign off important changes to the application, particularly if legislation is involved.

Application vendors may not want to migrate all of your current instances so it’s worth checking how your release management processes may be affected and how these may impact on business colleagues.

Always check how disk space and backup will be charged and try to predict growth to ensure you’ve budgeted for future headroom. Remember that major upgrades, enhancements and changes to audit requirements can have a huge impact on data size.

Connectivity

As with any service that’s delivered remotely, you should ensure that work and costs to increase connectivity resilience are included in any appraisal.

Many software suppliers will use IPSec VPN’s across the internet to give you connectivity, but make sure you have sufficient resilience in your Internet links, proxy servers and firewalls.

Components

A SaaS solution may take some of the headache away of managing software, but you’ll still need to check that you still have the capability to deliver it to customers, particularly if the way in which the application is delivered will change.

An existing locally installed thick-client application may be upgraded to a web-only version if you migrate to SaaS, so consider things such as:

Required upgrades to internet browsers

Oracle Java

Citrix

ActiveX components

On occasion, some of these components may require updates to operating systems and hardware, so you’ll need to check if your desktop estate is up to specification.

It’s also really important to check the version numbers of these components to ensure they don’t conflict with any existing software that your organization is running.

How to procure software as a service

The work involved in procuring a SaaS solution will be very substantial, particularly if you need to go to tender so it’s really important to seek legal counsel on such topics as audit requirements, time scales, performance, future termination arrangements, and more.

Tread carefully…

Software as a service and platform can really provide some great benefits for an organization, but it’s really important that you understand exactly what the implications are.

It’s well worth treating any migration appraisal as a project in its own right; I firmly believe that a large-scale SaaS migration is an organizational decision and one that should not just be lead on technical merits alone. So make sure your business case for migration stacks up.

For those organizations that are considering SaaS to avoid the costs of replacement kit, PaaS may be a more palatable solution in the short-term to help you move towards the cloud.