More than three decades of experience managing complex z/OS environments, cross-functional teams, and multi-million-euro programs for global enterprises.

With a proven track record across international high-availability environments, this practice offers senior-level z/OS consultancy tailored to the precise needs of each client engagement.

Targeted resource augmentation

Organisations responsible for z/OS environments frequently encounter resource constraints, project-driven demand peaks, or the requirement for interim technical leadership. This practice provides precisely scoped engagements — from specialist staff augmentation to short-term project management — drawing on extensive international experience within mission-critical infrastructure environments.

ISV migration consultancy

ISV migrations within z/OS environments have become an increasingly prominent area of consultancy, particularly where complex contractual frameworks are involved. It is a widely underappreciated fact that virtually all ISV products are capable of migration and replacement within a z/OS environment. Furthermore, many products can operate in parallel for extended periods, affording clients the opportunity to conduct direct comparative evaluations and substantially mitigate transition risk, address training for a smooth cut over.

Centralised maintenance distribution

Software distribution within complex z/OS environments frequently reflects accumulated legacy practices that impede operational efficiency. Since 1998, IBM has invested continuously in parameterisation capabilities — most notably System Symbols — to address this challenge. Through the appropriate combination of tooling and architectural configuration, maintenance can be distributed efficiently from a centralised repository beyond Sysplex boundaries, delivering consistency, governance, and long-term operational resilience.

z/OS performance analytics

Landmark engagements that defined careers, transformed institutions, and moved mainframes across continents.

A continuous trajectory of increasing responsibility — from permanent technical roles to founding and leading consultancy firms across Europe and beyond.

Operating across the EU and UK, Werner's current firms deliver hands-on z/OS consultancy and project management for enterprise clients with mission-critical mainframe environments.

Article 1 of 3 — "The renewal date sets the clock, not your project plan"

Most ISV replacement projects don't fail on technology. They fail on arithmetic.

Here's how these things actually start: budget pressure lands, or the incumbent vendor arrives with fresh ideas about licence cost. Someone looks at the renewal date. And that date — unlike almost everything else in the programme — is already fixed. It was fixed before a single line of the project plan existed.

That has one consequence people consistently underestimate: the timeline is non-negotiable. Every assessment, every proof of concept, every migration and cutover activity has to fit inside a window someone else drew.

Teams that discover this late spend the whole project in compression. Options narrow, the "big bang" migration becomes the only route that fits, and negotiating leverage evaporates — because the vendor knows your deadline as well as you do.

Teams that start the assessment early get something different. The deadline stops being a threat and becomes a planning constraint like any other. You get to choose your migration route rather than accept the only one left. You get to walk away from a shortlist.

The lesson is unglamorous: the earliest work in a replacement programme isn't technical at all. It's knowing your contract dates, and starting the analysis while you still have room to move.

Replacing an ISV product doesn't have to be dramatic. But you only get the calm version if you start before the clock does.

TBC…

Article 2 of 3 — "Make vendors prove it, don't let them pitch it"

There's a moment in every product replacement where a vendor shows you a beautiful demo and everyone in the room relaxes. That moment is where the risk enters the project.

A three-step discipline avoids it.

Step 1: Start with what you actually use. Before any vendor is involved, investigate what's in place. Not everything you're licensed for — the functionality genuinely in use. Assess the replaceability of each component, the scope for running old and new in parallel during changeover, and the fit with your future platform strategy. The output is a function matrix, built independently. It's the single most valuable artefact you can own, because it's the one thing the vendor didn't write.

Also map who is affected, because disruption isn't uniform:

Step 2: Make them prove it. Expect a proof of concept in your own test environment, running your workload — not a reference demo on someone else's data. No proof of concept, no place on the shortlist. Then review the solution design document. Every functional gap named and owned before signature. Because the design you agree here is the design you get.

Step 3: Re-run the analysis with the incoming vendor. Revisit products and vendor together. Revise the parallel-execution plan with the vendor in the room. Agree the migration route explicitly — big bang, parallel run, or phase in and phase out. Validate your function matrix against the vendor's own claimed capability. Test the future strategy rather than assume it.

You'll walk away with a product matrix that is rarely a 1:1 mapping — and it's far better to know that now than at cutover. You'll also have an SDD with a comprehensive change description, which is what drives the statement of work.

Pitches describe capability. Proofs of concept reveal it. Only one of those belongs in a procurement decision.

TBC…

Article 3 of 3 — "The people in the room and the paperwork that saves you"

Once the analysis is done, replacement programmes turn on two unfashionable things: who's involved, and what's written down.

Build the case, then commit. Obtain licence and service proposals from candidate vendors through an RFP. Calculate project cost and return on investment. Describe every KPI clearly before work starts — KPIs defined after the fact are marketing, not measurement. Document all actions and decisions. Sequence the migration. Then kick off with confidence rather than hesitation.

Who you need in the room. On your side: a lead project manager, an architect, subject-matter experts (systems programmers, DBAs), a change manager, and a PMO owning documentation and governance. On the vendor side, the mirror image: vendor project managers, a vendor architect, vendor subject-matter experts. When those pairs don't exist on both sides, decisions stall at the interface.

The documents that take the risk out.

And on that last point — a Gantt chart is not a project plan. It's a picture of one. The plan is the reasoning: dependencies, decisions, owners, and what happens when a date slips.

None of this is exciting. All of it is why some replacements land quietly on a weekend or in parallel mode and others become a story people tell for years.

TBC…

A deep and current toolset spanning IBM mainframe infrastructure, security, storage, performance management, and project delivery platforms.