Moving an existing CosmosDB database/collection to CosmosDB Serverless when using MongoDB

Introduction

If we go several years back, I already leveraged the instant scaling of CosmosDB… Recently a new plan has been introduced to cover this behavior, being the Consumption Based / Serverless option! For a new project I immediately started using this one, and I am very happy about it. Where I came to a point where I said to myself, let us migrate the other databases (where fit) to this option too. For today’s post, I will go into the differences I noticed… and hopefully save you some time looking up things. 😉 Though be aware that I have been leveraging the MongoDB API/endpoint.

Cloud Migration Strategies – The Subway Map!

A while ago I saw a kinda flow chart / subway map entailing the various paths to migrate your workloads to the cloud. My personal view on the matter differed slightly from this, so I’ve mocked up my own version…

 

 

The various tracks ;

• “Retire” ; For the workloads that are not relevant anymore to the business… decommission them.
• “Re-Host” ; A typical “lift & shift” scenario where you move the system “as-is” to the cloud.
  • Variant “Manual” ; Tedious effort… doing a manual rebuild of your systems in the cloud.
  • Variant “Automated” ; Work via migration tooling or redirect your automated deployments.
• “Re-Purchase” ; Some applications are not compatible with cloud platforms. Therefore it might sometimes be interesting to purchase another software suite. Where you’ll join the manual track once the implementation starts…
• “Re-Platform” ; Cloud provider typically offer “PaaS”-services too, where an On Premises deployment only favors “IaaS”-thinking. Examples here ; IIS on premises vs Webapps in the cloud.
• “Re-Architect” ; If you have control over your application, you might consider to refactor it towards cloud native components. Given, this is not always an easy/cheap task, but it’s a play considering the long term.

But for all, it starts with ;

• Discover ; Identify all the workloads in your IT landscape.
• Assess ; Investigate their readiness towards the cloud and which migration paths are viable.

And “ends” with ;

• Validate ; After a “construct” / “deploy”, always validate (test) if everything is according to your expectations / specifications.
• Transition ; Never forget to ensure that your operational team is ready before the “go live” of your workload.
• Go-Live ; The moment your customers will use the workload. 🙂