About the roleWe are re-platforming a national public-sector system in the EU: -750 screens of a legacy client-server 4GL (Uniface), rebuilt as a modern Java/Spring + React application on top of an Oracle database.
The hardest question on this project is not "does the new code work" - it is "does the new system do exactly what the old one does". The legacy system has decades of business rules encoded in screens and PL/SQL, much of it undocumented. Someone has to dig those rules out, write them down, agree them with the client, and turn them into the criteria that decide whether each migration wave goes live.
That someone is you. You own the business specification and the quality bar, you work directly with the client's domain experts, and you lead a team of two QA/BA engineers who turn your criteria into automated tests.
What you will do• Own the business specification, agenda by agenda - run workshops with the client's domain experts and end users, and turn undocumented legacy behaviour into written, unambiguous business rules.
Define the parity criteria for each migration wave - the acceptance contract that says "the new system matches the old one". On this project the specification and the test oracle are the same artifact, which is exactly why these two roles are combined.
Lead the QA function - QA/BA engineers report to you. You set test strategy, prioritize, review coverage, and own the quality gate that decides whether a wave is ready. Your team writes the automation; you decide what it must prove and you review it critically.
Reverse-engineer the legacy system - read the old screens, trace behaviour, and ask the right questions of the backend team when the answer lives inside a PL/SQL package.
Own UAT with the client - plan it, run it, and drive defect triage through to closure and sign-off.
Keep everything traceable - every business rule maps to a screen, a test, and a wave. Public-sector delivery is audited; traceability is not paperwork here, it is the deliverable.
What we expect (must-have)• 6+ years in business analysis or QA leadership on complex business systems - you have owned specifications that other people built and tested against
Elicitation skills - from people and from systems - you can run a workshop with a domain expert, and you can reverse-engineer behaviour from an application nobody documented
Written precision - your specifications are unambiguous enough to be used directly as acceptance criteria and signed off by a client
Test strategy ownership - you have decided what gets tested, at which level, and what blocks a release; and you have enough technical depth to review an automation suite critically, even though you are not the one writing it
Strong SQL - you check data in Oracle yourself rather than asking a
developer to check it for you
Experience leading a small QA/BA team - task assignment, prioritization, review of other people's output
Strong English - you will run workshops, write specifications, and negotiate acceptance directly with an international public-sector client
Comfortable working AI-first - you use AI tools daily for drafting specifications, generating test cases, and analysing legacy behaviour; we expect it to multiply your output, not replace your judgement
Nice to have• Domain knowledge in social insurance (or pensions, benefits, other public-sector welfare systems)
Experience with a legacy migration - parallel run, cutover, wave-based rollout, or reconciliation between an old and a new system
Hands-on automation background (Playwright, Selenium, REST Assured, Postman/Newman), even if you no longer write it daily
Accessibility testing against WCAG - it is a legal requirement for EU public-sector systems
Public-sector delivery: audit trails, traceability matrices, formal acceptance procedures
Why this role is interesting• You own the question the whole project is judged on. Parity with the legacy system is the acceptance criterion for a national system - and defining it is your call.
Real archaeology, not ticket grooming. You are not writing user stories from a backlog someone else wrote; you are recovering business rules that exist nowhere but in a 4GL screen and in the heads of the people who use it.
Both halves of the job in one role. Specification and verification stay in the same hands, so nothing gets lost in translation between "what it should do" and "how we prove it does".
Short decision path. You work directly with the project's PIC / product engineer - no layers between you and the decision.
Long-horizon project - a multi-year modernization program, not a three-month body-shop gig.
Tech stack• The domain: public-sector social insurance agendas - pensions, benefits, contributions
The legacy source of truth: a Uniface client-server 4GL application, largely undocumented, still in daily production use
The new system: Java/Spring backend over a frozen Oracle PL/SQL API, React SPA frontend, Keycloak, OpenShift
Your tooling: Jira / Confluence, a test management tool (Xray, TestRail or similar), and SQL against Oracle - you verify data yourself
Owned by your team: automated regression suites (API and UI level), run per wave in CI