cloud application migration

Five Pitfalls to Avoid for Successful SaaS Application Migrations

The decision to migrate an application to the cloud is not as difficult today as it was when the cloud was still an emerging technology. Despite challenges with security and integration with corporate systems, Software as a Service (SaaS) has become the advisable choice for many tactical IT services. Indeed, according to IDG’s 2016 Enterprise Cloud Computing Survey, 70% of organizations have at least one application in the cloud, showing that the promises of accessibility, usability and simplicity of deployment have delivered exceptional value for even the largest companies.

However, SaaS application migrations are not without challenges. There are differences between SaaS-based solutions and traditional on premise solutions. These differences need to be understood in order for organizations to align their migration effort to business use cases. Because the characteristics and constraints of SaaS applications contrast sharply with the needs of predecessor applications, the models IT traditionally uses to deploy enterprise applications will have blind spots. Whether your company prefers waterfall or agile principles, these migrations require a tailored implementation approach and support structure.

Unfortunately, many organizations get taken in by the polished promises of SaaS providers in the sales stages and fail to recognize these challenges or underestimate them. Five pitfalls are common, most grounded in assumptions that a SaaS solution will deliver functionality ’off-the-shelf’ in a manner seen in demos that does not take into account the differences between on premise and SaaS solutions or the complexity of integrated systems and processes.

ASSUMPTION 1: SaaS applications deliver benefits instantly

By definition, SaaS is intended to be simple to implement. Most SaaS applications have free account options and can literally be enabled and used within minutes. However, for many core business applications, the chances are good that your application will be part of an integrated and network-dependent environment. Problems quickly arise when requirements are not fully understood and applications are implemented hastily and without engaging all impacted parties.

To address these challenges, plan for time to integrate your SaaS project into your organization’s wider cloud strategy, taking into account your policies for IT security and IT infrastructure.  To simplify adoption, you may want your application to be integrated with enabling services like single sign-on, LDAP or AD integration, network optimization, mobility solutions, and end point configuration (e.g. group policy, internet options, and local permissions.)

ASSUMPTION 2: SaaS comes with ready-made compliance

Don’t assume that compliance comes ‘off-the-shelf’ with a SaaS solution, even if the marketing says it does. The SaaS application in a vacuum may have all the compliance classifications you require, but integrations and configuration will impact compliance to your required certifications. Your company’s cloud strategy may even have unique security and monitoring solutions like cloud access security brokers (CASBs) for compliance and risk that you need to take into account. Whatever the situation, if specific certifications like HIPAA or PCI are a requirement of your application, be prepared to validate the end-to-end solution for compliance. This can be addressed by engaging the information security and compliance teams early in the project, and keeping them informed of the configuration-specific design as well as any integration points.

ASSUMPTION 3: The intuitive user interface will minimize the need for user training

The best SaaS applications lead by having exceptional user experiences and user interfaces.  Many are often deemed intuitive by the pickiest of users and this often leads to an underestimation in the level of training required for user adoption. A move to a cloud application will incur significant business process change irrespective of the user experience of the application and will require change management focus and expertise.

Indeed, in successful cloud migration projects, change management is the critical component that drives the methodology and deployment plan.  Realizing the ROI of your cloud investment is predicated on your users’ willingness and ability to adopt, more so than the implementation approach.  Moving from on premise to the cloud is a substantial change in and of itself and will affect business processes like provisioning, data retention, business continuity, and compliance audits.

ASSUMPTION 4: SaaS is always available

One of the selling points of SaaS is that users can access the cloud service from anywhere and that availability, capacity, and recovery are managed for you. However, although most SaaS applications have robust high availability and disaster recovery architectures, many are not immune to large scale global outages like the Dyn DDoS event of October 2016 and the AWS S3 outage in February 2017.  Many peripheral factors can impact the availability of your SaaS application, such as expired certificates and firewall changes, some of which are managed by you and not the SaaS provider.  SaaS providers will also often have their own maintenance windows to perform updates on the application or service.  Customers of the SaaS application frequently do not get a voice on when the maintenance will occur or the duration.

Business resiliency should be designed-in with consideration to all integrated systems. In situations when high availability is not as critical, at least be prepared for occasional downtime and ensure processes and data can seamlessly transition without error when services are restored.

ASSUMPTION 5: You can customize SaaS to fit your needs

Every IT project faces a common dilemma: how to manage inevitable scope creep. Scope creep is not inherently bad and is addressed in agile principles by embracing prioritized changes as early as possible. In migrating to a SaaS solution, however, it’s common to carry this mentality into the process with the assumption that customizations can and should be implemented to cater to current business processes. With SaaS applications, however, the total cost of ownership of these customizations will likely be more costly than similar customizations to predecessor applications due to the rapid release schedules of SaaS providers and the rapidly evolving landscape of “as-a-service” in general.

SaaS applications function best when using workflows and user experiences as designed by the provider. Most SaaS applications are intended to be configured, but not highly customized. Although users may prefer the new system to work exactly like the prior system, it’s best to commit to mandatory customizations only.  Otherwise, you will be setting yourself up for unnecessary technical debt and costly forward maintenance. To mitigate scope creep that comes from over customization, ask your user base to try to the solution as-is for a three to six month period to allow for a hands-on experience.  You may find that “hard” requirements to change system workflows to resemble workflows in a prior system will melt away as users adopt and adapt, saving time and money from reduced complexity.

Conclusion: We are live! Users are happy! Now what?

Avoiding these pitfalls is not only possible, but less difficult than you might think. One recommendation is to partner with a consultant to be the liaison between business stakeholders and technical implementers and manage the migration with an eye toward prioritizing ROI and maximizing value for application users.  Another recommendation is to adopt a crawl-walk-run approach to transforming in step with the technology, and not move too far ahead of it.