Hey Andy,
I was only able to find this mention. Could you update this thread with the contact you’d mentioned in our offline conversations?
There are currently two small deployments in the mLab instance.
If I remember correctly their connect strings are defined within the applications build process in the encrypted configuration file. I’ve just read over the SOPS changes that we use to manage this file. I’m quite pleased with those changes, it’s certainly a much stronger portion of the process now.
I took a look at the plan options available to us in the new platform, mongoDB “Atlas.” They have a comparable plan to the free sandbox one, but it lacks backups.
We could go through the migration process, the documentation I have is what was included in the notification Andy and I received.
https://docs.mlab.com/mlab-to-atlas/
https://docs.mlab.com/how-to-migrate-sandbox-databases-to-atlas/
There’s a lot written in there but basically you move the data over and point at a new endpoint. Part of me feels that because of this fact it may do well to simply stand up a mongo container on some of the instances we already use and fill our data in that, but it means we’d be responsible for the consistency and availability, as well as the backups; which are a nice thing to not have to manage.
Depending on how much of the migration process relies on the new service creation in Atlas, it may be best to simply populate that and set up some bare minimum backups to dump every now and again.