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)
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
If you’re migrating applications for a larger
organization that has invested significantly in 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.
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
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
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
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.
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?