Showing results for 
Search instead for 
Did you mean: 
Create Post

Important Actions After Cloud Migration

Level 10

Cloud migration follows the same principles as any other complex task. With methodical planning and appropriate preparation, it can be a smooth and painless experience. While “divide and conquer” can have negative connotations, it’s a popular technique in computer science and can be applied to program management equally.

Assuming a migration was planned as such and all workloads are in the cloud now, does that mean the job is done? Absolutely not! There are several tasks that should immediately follow, some of which should become iterative processes going forward.


Immediately after migration, it could be all high-fives on a job well done. However, it’s crucial to do a clean-up immediately after, including shutdown and removal of any redundant systems, severing of superfluous network connectivity, and switching to production status of relevant applications on the cloud platform.

These actions are extremely important from an operations standpoint. The cost of running those extra resources is one thing, but those systems are easily forgotten over time. While they exist, they only cause operational confusion and security issues. Action should be taken to do a controlled but prioritized decommissioning of such systems and connectivity.


Once closure has happened and the platform is stable, evaluate if the migration was successful and achieved all it was set out to do.

The first point of reference is the business case that was formed as part of the project initiation phase where all stakeholders agreed it makes sense to migrate to a cloud platform. The other one is the list of KPIs (key performance indicators) that were defined as part of the audit that was defined just before carrying out the migration.

The latter is tangible proof of what was gained from the whole exercise. You should be careful that the measurements are “like for like” and the target objects will exist in their current form post-migration when defining the metrics, so there’s no confusion. Such evaluation and documenting before and after the migration is important as it keeps the team honest about their goals and any decisions made. At the same time, it also makes success undeniable.


Sizing of machines is one area where you should err on the side caution and oversize. That combined with the fact that in the early days applications tended to live in both environments, increases the running costs in the short term. Once the dust has settled, it is time to focus on optimizing for costs. Most cloud platforms offer discount pricing for infrastructure and native tools to determine where such savings can be made.

This is a quick and easy win. Furthermore, it’s easy to identify machines that will be required permanently and are good candidates for discount pricing by committing a certain amount to the vendor. In some cases, further savings might be possible by standardizing certain types or family of instances. A review should be done every year to determine how many resources can benefit from such discounts.


Speaking of cost optimization, another way is to refactor applications so that they can benefit from on-demand resource provision such as “function as a service” architectures or even stateless applications where infrastructure can be deployed for the duration of the job and destroyed thereafter.

Major cost efficiencies can be found using cloud-native technologies and methodologies. The best part is that due to the nature of the public cloud, such refactoring can be done in isolation and tested at full-scale in parallel.

Small and manageable improvements can be made over time to gain those efficiencies and that work should become part of an ongoing process to improve applications.


In the coexistence phase during migration, security policies have to allow traffic and system access between applications on both environments. Those policies need to be reviewed immediately after decommissioning of the “legacy” side of the application.

There could be a tendency to wait until all legacy applications are decommissioned but by doing so, you’d be introducing a security risk for the duration of the migration. While it can be a tedious process, any security breaches will end up consuming even more time, so it’s best dealt with as soon as possible. The security review shouldn’t be limited to just the legacy workloads. Security for cloud platforms is very different from traditional platforms, and migration provides an opportunity to review the capabilities available and take advantage where possible.

Center of Excellence

The migration team goes through many highs and lows during this process. That not only improves bonding but also develops a lot of skill and knowledge.

That knowledge is priceless, and it would be a shame if that team disbands completely and goes back to their “day job.” Technical members of the team will likely continue with the new platform, but other members will also have precious knowledge of the whole journey and shouldn’t be ignored. It makes sense to preserve that knowledge and experience by keeping the team as the “Center of Excellence” for the long term. It should reserve time and meet on a regular basis for strategic discussions and decisions going forward.


Migration to the cloud is no mean feat, but once achieved, it opens up so many possibilities to morph the infrastructure and tools into something in line with modern-day architecture.

This list is by no means exhaustive but does give a good start. As cloud technologies and skills to use them develop, only the sky is the limit—no pun intended!

Level 13

Thanks for the article

Level 14

Thanks for the article! 

Level 14

Excellent points.... Terrific article

Level 16

Thanks for the write up!

This!  So much THIS!

The above article should be required reading, retroactive via time machine, for anyone considering the cloud as a solution.

I don't see the logical follow-up to the possible discovery that one or more KPI areas do not meet expectations.  That area needs expansion, with definitions of:

  • Discovery and Validation:
    • What doesn't add up?
    • What did we expect, and what are we getting instead?
    • Why did we expect what we're not getting?
    • Were we unrealistic in our expectations, or not?
  • Results:
    • Did we achieve what we expected?
    • Can the CSP improve our results?
    • What will be the costs for upgrades that will bring our results in line with expectations?
  • Expectations:
    • Will we need to redefine our expectations?
    • CAN we even achieve our expectations?
  • Consequences:
    • Are legal actions against the CSP required, or appropriate, or necessary?
    • If the CSP promised X and delivered Y, can they be required to provide X without additional cost to us?
    • Can we live with Y instead of X?
    • What is the impact of Y to our customers?
    • How is our competitiveness impacted by only having Y instead of the X we require?
  • The Bottom Line:
    • How is the company's bottom line affected?
    • Do we have a competitive disadvantage when we only have Y to offer instead of X?
    • Will our customers migrate to other vendors?
    • Can our support staff still achieve our goals while remaining on budget?
    • Do we need additional training, personel, services, etc. to support Y instead of X?
Level 9

Thanks for sharing.  This is an important step, 'After the Cloud Migration' which many engineers skip.  Great lessons learned.

Level 20

Test and hope things work still...

Level 10

All great pointsrschroeder  Thanks for this addition and these points are definitely going into my notes

Level 10



Good article and rschroeder​ adds plenty of value here. (as usual)

Level 11

Good starting article, good response rschroeder, bottom line usually trumps the rest in our case, cost vs benefit.  Lots of good things to include in our reviews of systems/applications.


Thanks for the article

Level 11

Migration is always difficult