Migrating Enterprise Applications To The Cloud

Moving enterprise applications to the cloud can feel like a cumbersome and overwhelming situation for many executives and business leaders. Just the thought of moving your applications and data to the cloud can leave a feeling of uncertainty and insecurity, that your applications and data are no longer safe nor under your complete control.

But that couldn’t be further from the truth. The cloud can help you identify, detect and fix security issues by giving you access to powerful new tools to control your environment, instances, and even harden your security. You still control your applications, and data at the end of the day.

For starters, even if you kept your enterprise applications on site, it’s almost impossible to do business today without being in the cloud. For example, if your employees use business apps to collaborate, they’re probably already storing files and information in the cloud. And your off-site backup? Unless you’re shipping over boxes of tapes or drives, that’s in the cloud too. So if your organization is already benefiting from cloud services, why wouldn’t you leverage the power of the cloud for your enterprise applications as well?

The methodology used to migrate to the cloud is very similar to traditional data center moves. The approach I use for any cloud or hybrid migration is:

Strategic Alignment

During this phase, you need to document all business use cases and drivers leading your migration and transformation, assess TCO and ROI assumptions, and begin documenting what your end state goals and requirements will be. It is also important to identify strategic partners and vendors to assist with your migration project, and start to prioritize a series of timeline events and targets to get your project underway.

Cloud migrations, whether P2C, V2C, or C2C, takes careful planning, preparation and involvement from all areas of a client’s organization and business units.

Common strategy and migration approach questions you should be asking:

• How can I prepare my team and technology for a full-scale migration?
• How can I transition my organization from being hardware-centric to software-focused?
• What applications can immediately move to the cloud?
• What applications need to be rewritten or modernized for the cloud?
• What level of TCO and ROI can I expect to achieve?

Enhanced Discovery

Before moving a single workload, you must discover and map all of your applications, IT assets, and all of the inter-dependencies. Establishing this source of truth for your environment is critical to accurate migration planning. You must also take into account unique business case considerations while collaborating with application and infrastructure owners, project managers and business units to devise a lean migration strategy that not only moves your enterprise workloads, but looks at ways to optimize them for the cloud.

Analysis

Once you have completed Discovery, it’s time to start the Analysis phase. You should perform a deep review of the dependencies between applications, databases, servers, storage, network, etc. to determine hard dependencies that can’t be broken and soft dependencies that either won’t be impacted or can be temporarily broken during the migration. The goal is to define right-sized, move groups of assets that must migrate together so that you can later plan your migration events.

Given the transformation to the cloud from a traditional data center, a detailed analysis of the required application dispositions is necessary. There are six potential cloud migration options for your Applications; Rehost, Replatform, Repurchase, Refactor, Retain, and Retire.

Rehost

Also known as the lift and shift approach, most rehosting can be automated with workload migration tools but we do find some customers prefer to do this manually as they learn how to apply their legacy systems to a newly acquired cloud platform. Applications are generally easier to optimize and re-architect once they’re already running in the cloud. This is mainly because your IT organization will have a deeper understanding of the cloud platform it is now running on by being directly exposed to it and also the hard part is done, the migration of the application and data.

Replatform

Replatforming to the cloud, allows you to take advantage or make optimizations in order to achieve benefit or performance gain that has been plaguing your application, but you aren’t changing the core architecture of the application. You may be looking to reduce the amount of time you spend managing database instances by migrating to a database-as-a-service platform, or migrating your application to a fully managed platform.

Repurchase

Repurchasing is most commonly a move to a SaaS platform. Moving a CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, and so on.

Refactor

This is typically driven by strong business case needs to add features, scale, or address performance requirements that would be difficult to achieve in the application’s existing environment.

Retain

Maybe you’re still riding out some depreciation, or the application is just not ready to move. You should only migrate what makes sense for the business; and, as your transformation progresses from on-premises to the cloud, you’ll probably have fewer reasons to retain.

Retire

Once you’ve discovered everything in your environment, typically I would ask each business unit who owns each application and assess it utilization and need. I have found 10-20% of an organization’s IT portfolio can simply be decommissioned or turned off. These savings can boost the business case, direct your team’s attention to the application environments that employees use, and even boost security because many legacy apps and servers are prime candidates to retire.

Design and Planning

As you make headway on your journey and transformation to adopt or expand your cloud foot print and have a well populated library of excel sheets outlining all your environment and assets.
You can now start to mold your initial migration strategy into a detailed design and plan to execute against. This is typical no easy task. You must plan and prioritize move groups or waves of applications in such a way that minimally reduces the risk and downtime to business units involved. You must also asses your People, Process, and Technology. Are there gaps? Do I have all my vendors on board and ready to go? Are we using automated migration tools or manually moving servers? Attention to detail goes along way, and don’t be afraid reach out for assistance or bring in a consulting partner.

Moving to the cloud also poses some new challenges to assess, design and plan around the five pillars of a well architected cloud application; security, reliability, performance efficiency, cost optimization, and operational efficiency.

AWS has a great document called AWS Well Architected Framework that many principles found in it can be applied to almost any application being moved to the cloud regardless of cloud service provider. Document can be found here.

One of the main common mistakes I have seen, is to make sure that all your software licensing is updated to allow for testing during and after the migration. For example, if an application is licensed to a specific server, and not for the new environment, resolving licensing issues mid-migration will be difficult without impacting normal operations. And can result in missed timeline milestones during execution.

Execution

When you’re executing migrating enterprise applications to the cloud it should be structured in a way that minimizes disruptions to your business units and operational integrity. To the extent that it’s plausible, avoid migration activities or processes that will adversely impact the source environment or business units that depend on your applications and servers. That may be as simple as avoiding work on a heavily used database during normal business hours to prevent service interruption. This is also a great time to ensure that the target environment is properly configured. If there are any discovered issues or environmental conditions that need to be addressed, these should be re-mediated before the migration execution begins.

Properly configuring and testing the target environment with thorough validation by conducting the necessary load and performance testing is vital and will not only ensure a smooth transition, but also provide peace of mind regarding performance capabilities of your new environment after go-live.

About TransitionManager & TDS Cloud Professional Services

I came to TDS because I’ve been in the trenches for the past 10+ years of my professional career, performing large scale data center migrations and cloud transformation for some of the world’s largest companies. I’ve always eventually succeeded, but one thing every project I encountered lacked was a centralized migration orchestration tool with proper asset tracking, dependency analysis, migration planning, and execution runbooks for the entire project. We were mired in a pile of spreadsheets, word documents and project plans struggling to make informed decisions with a mountain of complex information. When I first saw TransitionManager, it was the tool I had always hoped for that handles and manages the entire end-to-end migration and transformation project.

You are able to complete asset and dependency mapping and tracking, breakout and model your entire migration from current state to future state, so that everything is tracked and executed with precision.

I’m also part of the TDS Cloud Professional Service Team, and the amount of talent here has been second to none. As a trusted partner, our Cloud Professional Services pays great attention and takes care to architect, migrate, and streamline your cloud transformation and adoption projects in ways that deliver valuable business results.