Email: info@s2infinitum.com

Cloud Migration

Cloud Migration

A lot of teams/organizations are pondering over the question of cloud migration and formulating the strategies around it: right from simple lift & shift of their tier 2/3 applications to the highly sophisticated approach of phase wise movement of applications/teams to the cloud with a hybrid deployment model to achieve best of both the worlds.

Indeed, there are benefits of moving to the cloud, provided you design and implement it right. A cloud proof-of-concept can quickly go haywire if not planned well. I have seen customers who spent almost a year on doing a proof of concepts and realizing that cloud migration might not be for them after spending close to one-quarter of a million in subscription costs. Team involvement and logistics cost extra.

If planned correctly, businesses can benefit from cost savings. They can convert the capital costs to better planned operational costs, by not having to install the hardware/software on the premise, additionally, the cost of licensing for premium software (like OS/DB license costs etc) is built into the subscription cost itself.

From the migration perspective, the operational cost modeling has significant implications for the organization, the management can push their team gradually to adopt cloud, without spending too much upfront and later realizing that rationalized cost benefits do not outweigh the migration costs. One of the most common friction points that I have observed is the reluctance of certain teams to cloud adoption itself. These teams own applications that have not been touched for years and people reach out to them in case of issues (which happens often), such teams love their power and their position. The most worrisome part of such team is that now they have to build the apps in more standard and transparent way (eg instead of opening non-standard ports, they now have to use REST services to communicate, or instead of using proprietary libs, they will be forced to use more open source libs and so on). It is the work of cloud architects to discuss and convince such teams on the benefits of technology standardization.

In a nutshell, the product owners need to sit with their architect team and discuss, whether they can really benefit from migration. They need to brainstorm and come up with points on why they need the cloud migration. In the long run, even a 10-15% of saving per year can translate into huge savings.

Once the technical and product owners have decided to do cloud migration, following point can help to smoothen out the cloud migration process:

1. Identify the applications for migration: In my opinion, starting slowly and gradually helps. Identify the applications that have low business impact at first and then move up the application chain.
2. Identify resources required for migration: Apart from the technical team, create a matrix of systems required on-prem vs the equivalent services on the cloud (so for DB on-prem, RDS service is the equivalent).
3. Identify data for migration: While doing cloud migration, data planning is a must. Storing data on the cloud has a cost, similarly, data going out from cloud to external sources also has a cost (incoming data is mostly free, but check with cloud vendor on your subscription limitations).
4. Use cost/pricing calculators: Both AWS and Azure provide costing calculators to identify the costs for running the migrated app on the cloud. The costing calculator can help to determine before-hand if migration strategy needs further refining (maybe drop 1-2 apps from migration plan). The above points will act as input to pricing calculators.
5. Create Cloud environment prototypes: Create a prototype for migration and design the cloud environment for others to follow. CloudFormation (from AWS) and Azure Resource Manager (ARM) templates can quickly help re-create the systems and topologies in a predictable way, so use these to create the environment often and repeatedly.
6. Plan to fix broken process: Cloud migration can be an excellent time to fix the broken processes and be agiler, so, for example, an old build/deployment process can be replaced with agiler CI/CD develops based processes.
7. Be Transformative in approach: Cloud is all about bringing transformation, right from how resources can be requested in real-time to make the process leaner and mean. Once, the teams have gained confidence with the cloud, start thinking of transforming your core business process to align with cloud practices. Don’t just look at cloud as means to reduce cost.

If planned properly, cloud migration can really help your organization to scale new heights and use technologies in ways that you thought were not possible, instant availability of Big-data clusters and sophisticated machine learning systems to analyse your data to help you gain upper hand over competitors to storing petabytes of data in storage or database at high levels of reliability, things that organizations were failing to achieve till now. Cloud has made it all possible. Have a happy migration.