Hi Pete,
Sorry for the late response.
The line numbers may change as the policies change from version to version (in some cases), so that would make sense. The instructions I had were what worked for one customer but you are likely using a different version of OTK than they were using. The lines needed though should be close to the original though - so it could still be as easy as just looking for the assertion names (listed at the end of each line) and replacing it with the Continue Processing assertion. I can't speak to the read-only part, that may be a new roadblock in this workaround that used to work previously.
I cannot speak to why CA still invoices you for maintenance of ESM as I am not privy to that information and contractual stuff, that is a completely different department. It's a fair question though and one that you can probably bring up with your account representative. If I were to hazard a guess, it's because ESM does migrations but not just migrations as it also monitors the status of all nodes in unlimited number of clusters, allows for alerting of various items if exceeding any kind of threshold, for example. GMU only does the migration part of what ESM did, they are two different tools with different roles to play, only overlapping a bit on migration functionality. For what it's worth though, under Broadcom, all of the licensing and contracts will be changing and so it may be a moot point very soon.