Developers in Banking/Finance: What's the one critical step that's always overlooked in a Mainframe to Java migration?

Posted by JobRunrHQ@reddit | ExperiencedDevs | View on Reddit | 41 comments

We all know the obvious steps like data migration, code conversion, and testing. But I want to know about the things that people don't talk about enough.

Those things that pushed the deadline 10 times and made the project go waaay over budget.

[-]

Ab_Initio_416@reddit

Finding and documenting the hundreds of regulatory and stakeholder rules implemented but never documented by generations of devs.

[-]

caffeinated_wizard@reddit

Oh boy a post I’m particularly equipped to talk about.

The rules/requirements can be written in dozens of binders and known ahead of time but the actual hard part is always the stupid data. Some guy created an account 45 years ago before people needed a SIN or some weird stuff like that. It’s always the data. And there’s an ungodly amount to deal with.

Performance is also going to be worse for the money pretty much no matter what. Mainframe is FAST and you’ll likely be able to process 10x the users or transactions in a fraction of the time. Nobody is replacing mainframe for Java hoping for better performance.

[-]

Dave-Alvarado@reddit

I am forever amused by the people who don't understand that "up" is a direction you can scale.

For some workloads, you just can't scale out nearly as efficiently as you can scale up. Big iron will always have a place in the computing world.

[-]

New_Enthusiasm9053@reddit

Though a commercial server scales up more than mainframes, it won't be as reliable. But mainframes are not what you use if you care about raw compute.

E.g IBM is currently on apparently 30 cores a socket vs 192 for AMD with IBMs Power 11 on a 7nm process and AMD on 3nm.

So if you solely want to scale up without needing the (truly impressive) reliability of a mainframe then regular servers are still better.

[-]

Pale_Height_1251@reddit

Mainframes are not Power 11, they are z15.

[-]

New_Enthusiasm9053@reddit

Those are even worse 12 cores a socket and a 14nm architecture. They can have 8 sockets in 2 racks but that means the entire system has less cores than a single socket Epyc server. So the Epyc will undoubtedly scale vertically much better because latency will be minimal on a single socket compared to a multi socket setup.

Though that was released in 2019, are you sure they don't have something newer?

[-]

Pale_Height_1251@reddit

You're right, they're on z17 now.

[-]

unconceivables@reddit

I chuckle every time I see people say they can just scale horizontally by spinning up more instances and the instances are garbage like 0.5vCPU/1GB.

[-]

dvogel@reddit

As someone who has had to consume some of the oldest data retained by Medicare, I can attest to this. Do not test the new system with data sampled field by field from the production system. Your sampling will miss important observations. Then your beautiful new database schema will reject many records because it fails to admit the world used to be very different than it is today. You need to make sure your test data represents every observable combination of values.

[-]

TacoTacoBheno@reddit

Add to that the test environment is polluted with garbage data.

Products that don't exist anymore, compliance laws have changed, etc. There's a whole lot of permutations.

And no matter how diligent you are, you'll never identify every edge case

[-]

CricketMysterious64@reddit

Sounds like a question one of the little Doge kids would ask before putzing around in government systems.

[-]

alanbdee@reddit

It should be done in a way that allows for parts to be moved one at a time with no hard deadlines. You move to the next part when it's ready, not when some arbitrary date is completed. This is probably done with the event sourcing pattern or event bridge where every event is published by the mainframe and then can be either consumed by the mainframe and/or the new java consumer.

[-]

NoobInvestor86@reddit

Havent done mainframe but this is exactly how we migrated off a legacy spaghetti-code, monolith system onto a more modern, distributed system

[-]

dvogel@reddit

I prefer to setup new data inputs outside the mainframe rather than making the mainframe distribute its input. Then the new system can be operated in parallel with the mainframe for testing. Then the mainframe can actually be disabled for a period of additional testing. If that additional testing fails it can be re-enabled and it will process the pending data as it would have if continuously enabled. It does take some care to ensure the mainframe processing has any assumptions of near-realtime processing removed to prevent time travel bugs when re-enabled. But that tends to be easier than retroactively establishing direct input to the new system by making it no longer accept input distributed by the mainframe.

[-]

JobRunrHQ@reddit (OP)

Nice thanks! The event bridge is a very smart idea. From your experience, is this something that most legacy mainframe systems offer, or does it need a lot of custom extra development?

[-]

alanbdee@reddit

I've never worked on a mainframe but I know a lot of sql servers have a feature to send messages along with queries being sent. But your best "injection" points will probably be in the middle of the processes. It's there you'll have to "send" a message and then "consume" it. But it's really hard to know more without spending weeks or even months coming up with a plan for your system.

[-]

tinbuddychrist@reddit

Documentation - nobody knows why the code is written in a certain way, and which parts are load-bearing for which things. (This is true for any type of migration or rewrite.)

[-]

DeadlyVapour@reddit

There are versions of Java after 8.

[-]

fishfishfish1345@reddit

i’m using java 23 and python 3.12

[-]

neopointer@reddit

I don't have any experience in particular with such a scenario, but I would strive for preparing the new architecture to migrate the customers slowly. E g. start with friends and family, do a lot of testing and then slowly progress on the customer base.

It's probably a massive dataset, so I wouldn't try to migrate all customers at the same time.

As opposed to what some newbies said, Java is excellent for the task, the hard part is to have competent ppl by your side.

[-]

puremourning@reddit

The 20 years since Java was a relevant target for such a migration ?

[-]

neopointer@reddit

What's relevant for that today?

[-]

briannnnnnnnnnnnnnnn@reddit

some day in the late 2000s you used your last applet and didnt even know.

[-]

Dave-Alvarado@reddit

"Don't try to migrate from the mainframe to Java" comes to mind.

[-]

eggrattle@reddit

Legit. Several Australian banks have tried. Spent millions, and years, failed and just gave up.

[-]

dogo_fren@reddit

Let’s replace a 60 years old tech with a 30 year old one.

[-]

musty_mage@reddit

Jesus that's dumb

[-]

tonydrago@reddit

Java 1.0 may be 30 years old, but Java 25 is only one month old

[-]

dogo_fren@reddit

And z/OS 3.2 is less than a month old. =)

[-]

disposepriority@reddit

True better replace it with next/nuxt/naxt express xtreme serverside serverless as a server service lambda microbaas cluster, written in rust obviously. Honeslty I'd hesitate to use a technology like java or c# because there's simply not enough social media presence.

[-]

TangerineSorry8463@reddit

You won't be so smart when you need to hire someone and there's 5 people in the country that could even apply for a mainframe position vs 500 that apply for a Java position in the first hour of the job posting.

[-]

JobRunrHQ@reddit (OP)

🤣

[-]

Synor@reddit

You seem to have a company already. Why don't you tell us?