[semyonsh]

So I'm guessing this will work mainly for customers that are running actual compute or K8S already?

The real challenge of a Cloud exit is undoing the years of gradually getting vendor locked-in. Not only do you use the services it provides, the software you might have written also uses the SDK's, is tightly coupled etc. I'm not even taking IAM into account, which is vertically integrated everywhere, in the equation.

And this isn't only on a technical level but also organizational. So i'm out of the cloud, my staff still doesn't know anything about managing dedicated servers and other solutions. I'm now fully dependent on a firm which main focus is doing migrations? How would that work?

What kind of business is your target audience here?

[avallark]

The last migration we did included a full kubernetes migration. We used k3s and it works beautifully on baremetals with an insane amount of resources now. Earlier devs were used to provisioning 0.5 cpus for a node, now they have so much resources to play around.

Very very important points about the sdks getting locked in into the prioprietary cloud s/w. This will need to be fixed by your dev team. However what we have noted is that the time and effort to fix these issues are much less when your dev team can ask a claude agent to look through code and make a particular feature of postgres x to be compatible for postgres y. This is a big committment of course.

We would assume that you will develop capabilities slowly to operate your infra, just like you have done for cloud. you can potentially use the same team that manages your cloud infra to do this also. contracting is probably the easiest to fix :)