October 24, 2026 at 12:00 am
Comments posted to this topic are about the item What Did Healthy Look Like?
October 24, 2026 at 2:29 pm
The first thing I would do is write a migration plan where the cost of going to the cloud exceeds the savings from the cloud. And if the system is as complex as you say it is- and likely contains at least some linked information that needs to be left behind on premises- you wouldn't even have to lie to do it.
Heck, even gathering the information for the plan is likely to burn more hours than the move to cloud will EVER be worth.
And present that to the financial department.
Ted Seeber
I find your secrets in your data.
http://www.informaitonr.us
October 24, 2026 at 9:07 pm
The word that sprang immediately to my eyes was "cutover." The plan is not to migrate service instances to new hosts and verify operations in a rational sequence. The plan is to turn off the current service and turn on the new one, and trust that no mistakes were made in the initial configuration. Good luck with that.
October 26, 2026 at 9:02 am
We import data from JSON files provided by a 3rd party each night. Every time they upgrade their system we have problems with the files arriving late (or not at all) or being considerably larger than before. Fortunately we have a table in the warehouse where we record file names, timestamps, sizes and number of records. The 3rd party always insist that their changes wouldn't have affected the files, but at least we're able to query this table and prove to them that they have. Without this, the conversation would just descend into "Oh yes you did", "Oh no we didn't" like the worst pantomime in the world.
October 26, 2026 at 4:23 pm
The first thing I would do is write a migration plan where the cost of going to the cloud exceeds the savings from the cloud. And if the system is as complex as you say it is- and likely contains at least some linked information that needs to be left behind on premises- you wouldn't even have to lie to do it. Heck, even gathering the information for the plan is likely to burn more hours than the move to cloud will EVER be worth. And present that to the financial department.
Not sure this would make a difference. Often the decision to move to the cloud is made before anything else, and financial calculations aren't always included. They're not simple either, as CAPEX v OPEX is a different tax treament, so comparing $100/mo v $150/mo isn't always obvious which is better.
There's also the challenge that some things do cost less in the cloud, but it requires behavior (and often code) changes. Those are usually approached with the best of intentions, and incredible optimism, whereas the reality across a few years sometimes goes a little less well than expected.
October 26, 2026 at 4:24 pm
The word that sprang immediately to my eyes was "cutover." The plan is not to migrate service instances to new hosts and verify operations in a rational sequence. The plan is to turn off the current service and turn on the new one, and trust that no mistakes were made in the initial configuration. Good luck with that.
I've seen the opposite with a number of customers. They are afraid to cutover and end up running both systems for a period of time. I had one client run in a dual mode, constantly updating data in the other system, for over a year.
October 27, 2026 at 11:29 am
The first thing I would do is write a migration plan where the cost of going to the cloud exceeds the savings from the cloud. And if the system is as complex as you say it is- and likely contains at least some linked information that needs to be left behind on premises- you wouldn't even have to lie to do it. Heck, even gathering the information for the plan is likely to burn more hours than the move to cloud will EVER be worth. And present that to the financial department.
Ha, I suspect a few finance teams would quite like that plan. You're right that gathering the information is a real cost, and it's usually much bigger than anyone budgets for... but if you don't do it your budget to move to the cloud doesn't tend to be very accurate! The problem is when people are told they're moving to the cloud after the cloud deal is already signed. I've helped teams where they were given a date to migrate and told a 10 year contract had already been signed!
October 27, 2026 at 11:31 am
The word that sprang immediately to my eyes was "cutover." The plan is not to migrate service instances to new hosts and verify operations in a rational sequence. The plan is to turn off the current service and turn on the new one, and trust that no mistakes were made in the initial configuration. Good luck with that.
Luck is definitely as essential component in any migration no matter what we do to be fair! I'd always rather have a period of running both side by side, so you can check the new system is behaving before you switch the old one off. It's slower and it costs more for a while... but it's a lot less stressful than finding out on Monday morning. And you still need to know what "behaving" looks like, which is exactly where the before numbers come in. (Though as Steve says, the trick is making sure side by side has an end date!)
October 27, 2026 at 11:33 am
We import data from JSON files provided by a 3rd party each night. Every time they upgrade their system we have problems with the files arriving late (or not at all) or being considerably larger than before. Fortunately we have a table in the warehouse where we record file names, timestamps, sizes and number of records. The 3rd party always insist that their changes wouldn't have affected the files, but at least we're able to query this table and prove to them that they have. Without this, the conversation would just descend into "Oh yes you did", "Oh no we didn't" like the worst pantomime in the world.
I love the accountability this sort of thing brings, and it's such a good point beyond migrations too. Having a single source of truth for the blame game is so important for keeping the relationship with the third party in a good place... nobody has to take anyone's word for it, you just look at the table (Also, "the worst pantomime in the world" is going to stick with me :D).
October 27, 2026 at 3:39 pm
I've helped teams where they were given a date to migrate and told a 10 year contract had already been signed!
Anybody signing a 10 year contract for software of *any* kind is foolish. Not even Microsoft offers 10 years of support on *anything* anymore. All binaries are outdated within 5 years.
And that includes "cloud" services.
Ted Seeber
I find your secrets in your data.
http://www.informaitonr.us
Viewing 10 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply