AWS Transform has just hit General Availability, and it claims to migrate Mainframe, .NET, and VMware workloads via the power of GenAI.
I’m skeptical that GenAI can turn itself loose and migrate workloads that companies have been struggling with for years, yes, but that’s not what caught my eye. No, at the same time, AWS updated its service terms with section 50.14, which as of this writing reads:
50.14. AWS Transform. By using AWS Transform, you agree to run the transformed workload on AWS for a minimum of 24 months from the date that the transformation is complete.
Okay, pump the brakes here a smidgen. I see a few problems here, none of them good.
First, and most ignorable: this is no doubt going to be turned into some AWS talking point in a talk, blog post, or investor call at some point, about “number of workloads migrated and still on AWS,” that presupposes the audience isn’t aware of this particular term.
Second, this is an unusually broad service term. It says nothing about the migration completing successfully. How many experiments have you run that didn’t pan out? “Well, we tried to migrate the mainframe using this tool, but FOR SOME ODD REASON it didn’t do much for the approximately 700 jobs tightly coupled to the mainframe’s workflows, so we can’t use the output.” That’s a realistic outcome—for which there’s no carve-out in this agreement term.
Third, it says nothing with regard to how far a post-transformation workload can be modified before it’s considered a different workload (Workload of Theseus, anyone?).
Part of my concern here is the very nature of these migrations. All of them (Mainframe, VMWare, and .NET) are notoriously complex beasts upon which companies routinely spend years and millions of dollars, many of whom end up cancelling part of the way through because of that very complexity. The workloads all invariably have years of accumulated technical debt, and migration tools therefore have to understand decades of massaged business logic and obscure integrations. When you sign up for AWS Transform, are you agreeing to run whatever comes out of the GenAI-powered sausage maker for the next two years—regardless of whether it actually functions for your business?
Further, what exactly constitutes “complete” in AWS’s eyes? S3 is 20 years old and if you call it “complete,” there are a bunch of very intelligent, very motivated senior engineering folks who will correct you rapidly and at great volume—as they should! Workloads are inherently ever-evolving; as engineers, I’m unconvinced we know what “done” actually means.
Perhaps you think, “oh, nobody ever reads service terms, they’re just standard boilerplate.” Sure, that’s correct—for you. But you’re probably not the target market for AWS Transform. It’s become increasingly clear that AWS is less about product-led-growth for developer tooling, and a lot more aligned with “give us money” enterprise marketing motions these days. But y’know what enterprises who run things like .NET, VMware, and mainframes care an awful lot about? That’s right: contractual terms.
Note that this restriction appears nowhere else: not in the blog posts, the social media announcements, the Transform documentation, the Transform FAQs, or the Transform pricing page (which currently simply says this service has no charges associated with it). Someone, somewhere is either confused, or not being upfront and transparent about this requirement. It’s not how AWS historically operates; they’re not Oracle.
This strikes me as suspicious. I’ve talked to a number of AWS attorneys over the years, and they uniformly strike me as smart, capable, and not the type to overlook something like this—which tells me this is either a massive blunder, and/or strategically intentional on AWS’s part.
What’s their motivation?
Why would AWS do this? They could be attempting to ensure they recoup their development costs, or (less charitably) they could be trying to prevent someone from using their service to do a bunch of heavy lifting, then hosting the output somewhere else. AWS is notorious for giving each service team its own P&L—which leads to a bunch of negative externalities. This could well be one of them. However, if this is true, they absolutely should be a heck of a lot more up-front about the requirement than they’re currently being.
I sure hope I’m wrong, because this is an ugly look for my favorite cloud provider. Adopting new service offerings should solve customer pain-points—not lock them outside on the building’s roof in the dead of winter. The bottom line: if you’re considering using AWS Transform, make very sure you have executive sign-off on this hidden caveat.
