Get it scoped →
Get it scoped →
A modernization programme fails when it is sold as one irreversible decision. This one is deliberately broken into stages that each stand alone: every stage produces something you keep, answers the question the next stage depends on, and gives you a natural place to stop. Read this page and you will know what happens, who does the work, and what we need from you.
Each stage exists to remove a specific unknown. The reason they run in this order is that you cannot price a full migration credibly until a pilot has shown how fast the work really goes on your code.
We parse an export of your estate and turn it into an inventory. This is analysis only — nothing is converted and nothing is changed.
You leave knowing the true size and shape of the problem.
We convert a small number of representative jobs — chosen because they are awkward, not because they are easy — and validate the output against your current results.
You leave knowing whether this works on your code.
A bounded slice of the estate — typically one subject area or application — taken all the way through conversion, validation and a rehearsed cutover.
You leave knowing the velocity that makes a full-estate plan real.
The first cutover that carries real business load, run with the safeguards you would expect for anything touching production.
You leave knowing it holds up in production.
The remaining estate in repeated waves, at a rate you have already observed rather than one you were promised.
You leave knowing the legacy licence can finally be switched off.
The stages above do not change. What changes is how much of the execution you keep. Most teams pick a model at the pilot, once they have seen the work, rather than deciding up front.
| Model | Conversion | Validation & remediation | Cutover | Best when |
|---|---|---|---|---|
| Convert Software only |
Your team, using the platform | Your team | Your team | You know the target platform and have people available |
| Guided Software plus support |
Your team, using the platform | Shared, with our engineers alongside | Your team, with our support | You want to own it but have not done a migration like this before |
| Full stack We run it with you |
Our delivery team | Our delivery team, to full reconciliation | Run with you | Your team knows the legacy system but not the target, or has no capacity |
These are the same three options priced on the pricing page, where you can also estimate a range against the size of your estate.
Blended delivery is how the economics work, but it only works if the split is drawn in the right place. Ours is drawn around who needs to be in your meetings and who needs to be in your code.
A small anchor group — typically a lead architect and a delivery lead — working in your timezone. They handle the parts that need to be in the room: scoping decisions, target design choices, working with your SMEs, coordinating UAT, and standing next to you at cutover.
The volume work runs from our India delivery team: conversion runs, validation cycles, remediation of flagged exceptions, and regression testing. This is the work that benefits from a larger team and from being handed off at the end of your day and picked up during ours.
The two groups overlap for part of each working day, which is when review and escalation happen. Outside the overlap, work continues against an agreed queue rather than waiting on a call, so a validation cycle can finish overnight instead of costing a day.
No. The platform is installed inside your perimeter, and analysis, conversion and validation all run there. An offshore engineer works through your access controls, on your infrastructure, under your logging — the same way any of your own remote staff would. Nothing is uploaded to us, and there is no outbound connection for the platform to phone home through. The mechanics of that are on the deployment page.
The most common reason a migration stalls is not technical. It is waiting on an export, an environment, or a decision nobody owns. This is the full list, so you can judge your own readiness before talking to anyone.
| Stage | From your side | Why it is needed |
|---|---|---|
| Discovery | An export of the estate in scope | The artifacts are what get parsed; no system access is required |
| Discovery | Someone who can say what is still in use | Inventories always surface jobs nobody can account for |
| Proof of concept | A target platform decision, even a provisional one | Converted code has to be generated for something specific |
| Proof of concept | A representative dataset and the current output for it | Parity cannot be proven without knowing the right answer |
| Proof of concept | Somewhere to install, and access to it | The platform runs inside your environment, not ours |
| Pilot | A named SME for the chosen subject area | Business rules need someone who can confirm intent |
| Pilot | A UAT window with real reviewers | Validation without a business sign-off is not validation |
| Production wave | A change window and the usual approvals | Cutover follows your release process, not a separate one |
| Production wave | Agreement on what triggers a rollback | Decided calmly beforehand, never during |
| Full estate | An owner for wave sequencing | Order is driven by dependencies and business calendars |
Everything below is yours as it is produced, not held back until a final milestone. If you stop early, you keep what the completed stages produced.
A catalogue of every job and program with complexity scoring and dependencies — frequently the first accurate picture of the estate a team has had.
Column-level lineage and source-to-target mapping documents, usable for impact analysis and for your data governance obligations.
Readable code in your target platform's language, in your repository, with no dependency on our tooling to run it.
Row-level and column-level comparison results showing the converted output matches the legacy output, retained as an audit record.
An explicit list of what needs human judgement and why, rather than silent approximation buried in generated code.
The sequenced steps, checks and rollback position used for the wave, reusable for the waves that follow.
There is no hosted step in the middle where your code sits on someone else's machine. Installation is usually the shortest conversation in the whole engagement.
Installed on your own hardware, behind your firewall, managed under your existing operational policies.
Your cloud tenancy and your accounts, sized to the estate and scaled down between waves.
Supported for environments with no outbound connectivity at all, which is the common requirement in banking and government work.
Requirements, install steps and the security posture are covered on the deployment page.
Yes. Each stage is scoped to stand on its own and to produce something you keep, so stopping is a normal outcome rather than a failure. Discovery leaves you with an inventory and dependency map of your estate that is useful even if you go no further, and a proof of concept leaves you with converted code and a parity report on your own logic.
You do. The output is ordinary source code in your target platform's language, held in your repository, with no runtime dependency on MigryX to execute it. That matters because the point of modernizing is to stop being locked into a tool, and you should not be trading one lock-in for another.
It is reported rather than guessed at. Embedded custom code, dynamically constructed SQL and platform-specific behaviour are surfaced in a review report with the jobs that depend on them, so you see the exceptions as a list you can plan around instead of discovering them during testing.
Analysis and conversion work from exported artifacts, so they do not need a live connection. You do want the legacy system available while validating, because proving parity means comparing the converted output against what the current system actually produces.
This is the normal situation and it is what the delivery models exist to solve. Teams confident in the target platform typically take the software and run conversion themselves, while teams without that experience have our engineers run execution and reconciliation with them, which doubles as knowledge transfer on real workloads rather than in training.
It works either way. Where an integrator already owns the programme, we are usually brought in for the conversion and validation layer while they retain overall delivery, and the inventory and lineage output tends to make their estimating more accurate. Where there is no integrator engaged, we can own the full path through cutover.
Neither one commits you to a programme, and both work on your own code rather than a prepared example. Pick whichever matches how your organisation prefers to evaluate.
A short session where we point the platform at code from your estate and you watch it parse and convert, with an engineer to answer the awkward questions as they come up. Best if you want to judge it quickly, or need something to show colleagues before committing time.
Take the software, point it at your own code, and see the output without a consultant or an RFP. Best if you would rather evaluate by doing than by meeting.
When you need a number, the pricing page estimates a range against your estate; the deployment page covers running it in your environment. Or email hello@migryx.com and describe what you are running.