If you want to launch your digital transformation efforts, a great first step is exploring possibilities within the cloud. We often find that transitioning one application at a time is the best approach. Testing the waters helps acclimate not just your technology teams to the cloud but your entire business culture as a whole.
However, there are some situations where a more ambitious plan makes sense. For example, the business may need to commit to moving multiple interdependent systems at once, due to vendor changes, technical reasons, etc. This generally means tackling higher complexity and accepting increased risk. For these situations, we develop a detailed, phased, long-term cloud transition roadmap. Even for a more conservative one-at-a-time strategy, it can be imperative to create a comprehensive roadmap to satisfy corporate governance or other long term planning needs before even dipping that first toe in the water.
Phase One: Planning
Step 1: Define Your Goals
The term “cloud” can be ambiguous. It often means something different from one person or company to another. It’s essential to identify and define your company’s goals before diving into your cloud migration.
We recommend asking yourself what your business truly needs from a cloud environment – is it a focused lift-and-shift of a current application or a broader strategy of digital transformation? If you’re looking to build something new, is it an internal system for your employees, a portal for your b2b partners, a customer-facing application, or some combination of all of these?
You’ll want to establish benchmarks to measure your success. It could be something concrete like improved application load time or a measurable productivity increase, or it could be an intangible like higher employee satisfaction. Define these key performance indicators first to help focus your plans, and so that you can know when to consider your migrations a success.
Step 2: Document a Preliminary Plan of Action
There are dozens of ways to move to the cloud when you consider all options, so don’t work from a template. Build a transition plan that works for your business with its specific needs and goals. We recommend covering as many details as possible during the planning process. This phase may make some stakeholders feel impatient to get started or some others worrying about spending too many resources on planning. However, the better your plan, the higher your chances for a successful outcome.
You’ve likely heard Dwight D. Eisenhower’s famous aphorism, “Plans are worthless, but planning is everything,” many times before. His point is that any sufficiently complex project is virtually sure to encounter unexpected circumstances which force you to deviate from the plan. The plan must be a living document which strives to anticipate as much as feasible and adjust quickly and efficiently when circumstances deviate from the plan. An effective project manager is crucial to managing the plan from the outset, from evolution to completion.
Strategize Your Initial Moves
A reliable tactic is to phase migration starting with one critical (or non-critical) legacy application, sometimes called “lift-and-shift.” A similar alternative is to replace/rebuild an existing legacy application. Taking this route allows you to pay down technical debt on a system critical to the core of your business. You can then migrate your users and data onto the replacement application. A third strategy is to prioritize the development of a planned new application that doesn’t yet exist. Considerations include how risky and how big should you go here? Outline not just your first application migration but the prioritized order of everything in your technology ecosystem, even if this puts you years out from a full transition to the cloud. This helps you and your stakeholders consider the big picture in one complete roadmap.
Important! While it’s premature to get deep into technical details, you need to weigh technical considerations along with business considerations during the strategy and risk evaluation phases. Include technologists alongside stakeholders in the planning from the beginning to reduce the risk of being surprised by hidden technical complications. Often these two representatives quite literally speak different languages, and that’s where an experienced business analyst becomes critical to synthesize the various concerns into a cohesive plan.
Risk Evaluations
Consider your comfort levels with risk. We’ve worked with “go big, or go home” companies who move a critical or ambitious system into the cloud first. We’ve also worked with organizations who move smaller, minimal-impact applications first, getting their feet wet before taking the plunge. Consider the resources you have and what you will need to add, both during the transition and for ongoing care and maintenance. Some applications will require more work than others. There are merits to each strategy, and it comes down to what works best for your business.
Choose carefully and consider cultural transformation shock. The impact of this first step is much like a first impression. If it goes poorly or isn’t rolled out to users well, your organization may resist later waves of cloud migration. If it goes well, they are more likely to welcome future migrations.
Technical Details
Once you have defined the order of operations, it’s time to determine more detailed resourcing and technical requirements for your transition.
You’ll want at least one architect resource on the team who has demonstrated prior experience working with the cloud provider you select. Not everyone on the team needs to be expert in the specific cloud you choose (e.g., AWS, Azure, etc.). However, if you assume that your otherwise expert team can learn the ins and outs of cloud setup and administration, you may be right. Make sure to factor in plenty of time on both the calendar and the resource’s workweek to get over the initial humps.
If the calendar is critical, you will want to include certified architect(s) with hands-on experience on the team. On the other hand, if you want your in-house expert(s) to learn the ropes, and the calendar isn’t critical, spend the time to send people to training. Then give them the time and opportunity to learn on the job in low-risk circumstances.
You’ll need to identify dependencies between different applications, and how their relationships will change if one is within your cloud environment and another is not.
Don’t forget about documenting plans for data security and privacy moving forward. You need to outline data protection strategies, especially as data moves in and out of the cloud.
Consider relevant industry regulations. Your business may not have to worry about this, but we’ve worked with organizations who have to follow regulations like HIPPA, GDPR, etc. Outline how to handle regulations while you’re in the planning stages to ensure that you include the right specialized expertise on the project team.
Step 3: Start Making Resource Changes
Transitioning to the cloud is a huge undertaking. It can take years to shift completely to the cloud. And that creates a new, sometimes permanent, strain on resources. Many businesses choose to work with a team of consultants, cloud solution architects, and software developers (like Soliant) to alleviate the pressure. However, your team will eventually need to learn how to update and manage your applications in a cloud environment, even if they won’t be taking over direct administration. They should be actively involved in the planning and implementation processes. How will they juggle other development and system needs during this time? What responsibility is the higher priority? Build a realistic resourcing plan, because you can only stretch people thin for short bursts before you risk burning them out or see quality suffer.
Adding Team Members
Sometimes this means hiring a new team member or two or dedicating a veteran team member’s time almost exclusively this undertaking. We recommend filling a new role(s) before a strain on resources becomes painful. We know how difficult it is to find talented technology experts. Start searching for the perfect team member(s) during the planning phase to help carry you through this transition. If you need help, our team at Soliant Consulting can help screen candidates for client in-house development teams.
Preparing DevOps
If you don’t have a DevOps strategy or team in place, your migration to the cloud is an excellent time to build one. You then must prepare them for this step, either through additional training, cloud-specific certifications, or resources. The advantage of a well-planned DevOps strategy is increased speed to market and quality of your software product(s).
Step 4: Build Your Timeline
All well-executed plans include a detailed calendar. Keep your team on track and accountable by building out a timeline for your transition. Get as much detail as possible and be sure to have a mechanism for measuring velocity and progress so that you can continually update the timeline based on actual measured progress.
Yes, complex projects usually deviate from the initial plan. You’ll run into issues nobody thought of – that risk is inherent in every complex development project. However, an accurate well-managed schedule can motivate your team to keep moving forward and to make up for any lost time. More importantly, it gives the business as a whole something to reference. It provides stakeholders with valuable information for planning adjacent activities, such as sales, marketing, help-desk, etc.
As with all migrations, your cloud migration strategy comes with choose-your-own-adventure variables. We’ve worked with businesses who go very slowly to mitigate risk as well as with those who want to go faster to meet more ambitious business goals. We recommend avoiding rushing the process. However, the slower you go, the more you will invest in communication over a longer timeframe and maintenance of two infrastructures until the transition is complete.
Phase Two: Development
Step 1: Cloud Infrastructure Setup
Your infrastructure sets the tone for your entire migration, so every decision you make during this step is critical. You cannot merely consider just your business needs now. You must also plan for your company’s future and how it will grow within the cloud.
Data Storage, Latency, and Provisioning
Moving to the cloud often requires a shift in assumptions. For example, backup strategies can be simpler and more cost-effective because cloud infrastructure doesn’t require managing physical media such as hard drives and backup tapes.
On the other hand, some on-premise applications might have to be re-optimized as users in a colocated physical facility may now connect to the application over the internet instead of the LAN.
The purchasing and provisioning of resources will follow a different model when you move from hardware to the cloud. Hardware is generally budgeted with a three to five-year amortization. Cloud infrastructure opens up new provisioning options that start with strictly on-demand resources for premium per minute cost. It can include cost savings if you can predict reserve instances on a one to three-year horizon.
Configuration Details
Configuration details can become similar to application code. This is where an effective DevOps strategy comes into play. Properly planned environments can be provisioned in a very automated manner in the cloud using tools like AWS Cloud Formation. This makes provisioning and configuring them highly repeatable and scalable, lending itself to faster time to market with higher quality.
Control Over Your Cloud Environment
Your technical managers should be hands-on with defining policies. You will need policies about how teams can request and provision new resources, as well as policies around access and security for both staging and production environments. Consider these in both business and technical realms. You can automate nearly everything, but you need a trusted team meshing them together so that they support and reinforce each other.
Step 2: Primary Application Development
Now that your environment plan is ready, you can start implementing it. Depending on your decisions and priorities, this could be quick, with a lift and shift, or it could be a major new build.
Don’t Forget Documentation
Cloud migration development involves many moving parts and often many resources. As one business unit may completely manage one component of the development process, documentation is crucial to cluing everyone else in. All requirements, decisions, and changes should be documented in a central location, accessible to all who need to know these details. Project teams often can document decisions and tasks efficiently in wikis, issue trackers, and version control repositories. Documentation especially comes in handy if a problem arises during QA. You can pinpoint what went wrong and update the documentation so that it does not happen again.
Some projects might also call for a more formal level of end-user documentation, usually requiring a specialized team to write and test.
Step 3: Testing
We recommend a rigorous internal quality assurance review. QA should involve more than members of your development team testing the code. Your business analysts will be looking for more than technical bugs and typically focus more on user stories than how it works technically, making them better proxies for real users. Even the best developers are notoriously bad at finding bugs in their own code. QA team members will ensure the application matches with the initial business vision outlined in phase one. If the project calls for it, assemble a dedicated QA team, and consider including QA engineers separate from the development team to write automated tests integrated into the deployment process. This will ensure a very high baseline of quality as you add new features.
Whatever QA process your project calls for, the normal next step for a new or migrated application is a user acceptance test. We recommend rolling out this initial application to power users within the business for formal user acceptance testing. Avoid the temptation to do this ad hoc. A project manager and/or BA should design the acceptance test plan because even power users can tend to assume that if something works one way it works every way. Formal UAT will help ensure that critical features are checked thoroughly. This helps catch anything that was missed during development and it allows you to consider incorporating user feedback in the less risky UAT environment before you go live to all users. Take feedback from these power users seriously. If they have concerns, you should too.
Step 4: Deployment
After user acceptance testing is complete, you will need to deploy your newly completed application with the current data. Depending on circumstances, this might call for a down-time while production data is transformed and loaded. Or, it might be as simple as changing a few settings.
Whatever the level of complexity, you should prepare your team for a period of hyper-care after launching the new application. You must actively monitor the application for issues and speedy responses to user problems. Often users are confused just because things are new, and they may need simple questions answered. Someone needs to be assigned and ready to triage support requests to separate these types of simple questions from actual bugs. The hyper-care point person or team will also work to reproduce bugs and characterize details such as version, environment, state of the data, etc. and write that up so that the developer(s) assigned to fix it can focus on the fix instead of tracking down how to reproduce the problem.
There should be a team and a plan in place for prioritizing and patching bugs. This team should include stakeholder(s), analyst(s), tester(s), and developer(s). The team should try to defer bugs for normal development release cycles if possible. However, they may have to highlight some bugs as high-priority to be hot-fix and push them to production quickly.
Two-way Communication is Key
Poor communication can completely derail even the best deployments. Start on the right foot by prepping all users before deployment. Let them know what to expect and share a user guide to help them understand changes in the system. The project manager should either communicate directly with the users or verify that the delegated communication point person has sent approved messages to the right groups at the right time.
You should also establish a formalized feedback loop to understand their reactions to the application in the cloud environment.
Remember, users will resist a new system if they feel confused, unheard, or caught off-guard. Get them on your side early in the game by helping them feel comfortable and prepared. Prepare to react to and incorporate feedback in an efficient and transparent manner.
Step 5: Rinse and Repeat
Now it’s time to follow your full cloud migration plan by going through this phase again with your remaining applications. Of course, if you’re following a more complicated strategy of moving dependent systems simultaneously, this will look different. However, the core of each application is the same. Planning > Development > Testing > Deployment > Support.
Phase Three: Maintenance
Your infrastructure and applications in the cloud require oversight. Much of this can be automated, but your team still needs to be reviewing opportunities for improvement. For example, should you scale up or scale back this month? The major cloud providers roll out new features at a dizzying pace. Someone needs to keep an eye on these releases to determine if you need to integrate one into your environment.
Backups
While we briefly touched on this above, we want to reiterate that planning for emergencies is paramount in technology. Consider details related to how you’re running your backups and how quickly you can restore from them. Determine if you have a full disaster recovery plan in place. Identify team members who have the power to restore the system and/or data versions. In many ways, backup and recovery are much faster and much simpler in the cloud. They do, however, require the same level of planning and testing as a legacy disaster recovery plan. The good news is, the cloud can make it simpler to run disaster recovery/resilience drills through automation. Your organization should consider detailed planning and so-called “GameDay” drills if resilience and/or fast recovery is critical to your business.
Security
Many people have concern about moving business-critical data to the cloud. However, it can be more secure than on-premise infrastructure. Due to its nature, cloud infrastructure is easier to update than physical infrastructure. DevOps should actively monitor and manage the infrastructure, and IT management has an important oversight and governance role to play. Developers must be empowered to seek ways to patch holes and mitigate threats with specific restrictive permissions in production environments. Also, consider network isolation and resiliency measures. Monitor integrations and APIs to ensure no weaknesses arise. Keep up on data encryption measures and constantly review user authentication and permission levels. Cloud infrastructure is not inherently more or less secure than any Internet-connected system. Arguably, a well-designed cloud infrastructure can be more secure than an Internet-connected on-premise one.
Starting Your Cloud Migration
We hope you’ve found this guide helpful as you plan your migration to the cloud. If you have any questions or would like to learn more about our consulting and development work in the cloud, contact our team today. Our AWS solution architects are happy to discuss your transition to a cloud environment.
