How To Move Aging Architecture And Applications To The Cloud
By Krishna Nair, 1Rivet
Got aging an application that doesn’t sit on the cloud but still has business value? When you finally decide it’s time to move it, the right strategic plan can deliver additional benefits for users.
If your organization is considering moving to cloud, but you have aging applications with outdated architecture, it might be a good time for you to invest in a long-term strategy to maximize the benefits. To make the most of those benefits and ensure a smooth move, the best approach is to follow a six-step strategy:
- Define clear objectives
- Limit scope
- Define target state architecture
- Create an implementation roadmap
- Build a prototype (for large projects)
- Execute
Let’s look at each of those steps.
Step 1: Define Clear Objectives
To gain clear objectives, you’ll seek answers to questions. Do you want to be cloud agnostic or do you want to start utilizing the full capability available with a cloud provider? Are you considering completely moving to cloud or are you considering hybrid?
If you want to remain agnostic, stay with IaaS implementation. IaaS is a good way to transition to cloud and could lead to quick wins. For a lot of legacy COTS products, this is the only option available. If not, explore PaaS capability offered by your cloud provider. PaaS delivers major benefits but requires higher investment to migrate/re-engineer. If you have external-facing and customer-focused applications, then PaaS would be a better choice.
Do you want to stick with existing technology or modernize your technology stack? Do you want to upload your development or integration pattern? Do you want to move toward microservices architecture?
If you’re migrating applications for a larger organization that has invested significantly on enterprise architectural components, like an enterprise service bus, look at the PaaS capabilities offered by various Cloud providers.
Do you want to do business re-engineering? You may have outdated functions underpinning your older applications. As part of your technology modernization, consider whether it also makes sense to re-engineer those business processes. It’s also a good time to consider how you can improve and update user experience.
Step 2: Define Interim And Target States
If you are moving toward cloud architecture, there might be significant technical and organization changes.
Cloud-based architecture is typically more inclined toward horizontal scalability, while traditional on-premise architecture is typically designed to be vertically scalable. A lot of organizations have already switched toward service-oriented architecture, but the technology has advanced significantly with DevOps and containers/VM.
Enterprise service bus in traditional SOA has been replaced by lighter API gateway or messaging queues.
Avoid the temptation to over-engineer your target state, which can add more objectives to the migration and delay everything. The target state is important, but everyone needs to understand it will evolve, so focus on creating an interim state based on target-state objectives.
Pay close attention to security in hybrid architecture. How do you connect the on-premise solution with the cloud solution? What data can exist in the cloud? How do you federate user information?
Organizationally, a cloud-based echo-system requires a different type of support system. The traditional infrastructure or production support team will require training so that they can be successful in their new roles and support the transition phase.
Step 3: Limit Scope
It’s easy to go overboard, so once you define the objectives try to keep the scope of the project from expanding. Most applications don’t live in isolation. They must integrate with other systems. Be clear about what stays in premise and what goes to the cloud.
To keep everything organized create a transition roadmap. Use it to keep everyone updated on what you’re migrating and when. Your objective, interim state and target state roadmaps are a great tool to limit your scope.
Many applications have an underlying database. While it’s often easier to move the database to the cloud using IaaS, moving toward DBaaS is a better long-term solution.
Since no major application exists in a complete silo, you’ll end up migrating more than one component. During the transition phase, you may have redundant enterprise capabilities in premise and on cloud.
Step 4: Build A Prototype For Larger Initiatives
If your target state is more than using VMs on cloud (IaaS), it means you may be going through a significant organizational change. Instead of directly starting with cloud migration, implement prototypes.
Set clear objectives for those prototypes and timebox them (4-8 weeks). For example: You may have one prototype to finalize the technical architecture of the solution and a separate prototype to finalize the target state DevOps pipeline. Clubbing both objectives to one prototype will just increase the timeline and delay the decision making.
Post prototype, everyone will have a much better understanding of the target state. The architecture team will have signed off on the architecture. The project manager or scrum master will have a better understanding of the dependencies. The entire team will have a better understanding of the overall design and how up-front investments, like automation or scaffolding, might reduce future efforts.
If the prototype is not successful, take those learnings back to the drawing board and redefine objectives.
Step 5: Create An Implementation Roadmap
Once you have all the inputs from objectives, target/interim state and prototypes, define an implementation roadmap that lays out every release. Even if your organization hasn’t adopted Agile development, it’s advisable to avoid waterfall or big-bang and instead go with iterative releases.
You don’t have to turn on the environment for the users to benefit from having smaller releases that let you measure roadmap progress.
Investing in accelerators up-front and evolving them will significantly reduce your effort and give you a more standardized code base.
Step 6: Execution
In this final step, you’ll execute (develop, test and deploy) your applications or technology components following the path you laid out in your implementation roadmap. Using Agile methodology, you’ll typically launch a new version for end-user testing every two to three weeks.
Investing in test case automation and CICD pipeline can significantly improve productivity. A deployment or infrastructure pipeline may have a higher initial investment, but long term, it improves productivity by eliminating dependencies with other teams (infrastructure or database admins) and cutss cost by reducing cloud charges by terminating environment when not used.
Moving aging architecture and applications to the cloud using a smart, strategic plan can bring great benefits to your users. This six-step formula has worked well for the many migrations we’ve done for clients – what’s worked for you?
About The Author
In his 14 years working at the intersection of audience and technology, 1Rivet CTO Krishna Nair has led large-scale integrations of systems and data, managed content across omni-channel platforms and worked with some of the best-known brands including Nike, Western Union, Verizon, Sprint, ADT and Harvard University. His global leadership experience driving technology excellence grew from his love of design and development challenges. He still likes to jump in and write code when challenges arise. Krishna enjoys mentoring and building highly efficient teams, both in the United States and in India. Before joining 1Rivet, Krishna was a senior technology manager at SapientNitro and a senior technology delivery manager at Fannie Mae.