Fifty state Medicaid agencies. Some running COBOL on z/Series. Some on C# middle tiers over legacy data stores. Some partially modernized, with specific subsystems updated and others untouched for decades. The technology varies. The crisis is the same: the people who understand what the system actually does are retiring, and nobody wrote it down. The decommissioning clock is running whether the state is ready or not.
DXMachine is the platform that makes decommissioning tractable. Not by replacing the mainframe in one move — but by capturing every workflow it touches, running them in parallel on real data until the proof is built, and producing the CMS-defensible audit trail that makes the transition documentable. The mainframe gets decommissioned when it has nothing left to do that DXMachine isn't already doing better.
Every prior attempt to decommission a state MMIS has failed or stalled for the same reason: nobody could prove that the new system covered everything the old system did. Workflows undocumented for thirty years. Edge cases in COBOL that nobody remembered writing. The risk of a missed eligibility determination or a failed claims batch stopping the transition cold. DXMachine solves this problem by making the proof of coverage continuous — built workflow by workflow, in parallel, before the decommissioning decision is ever made.
Every workflow the compliance team currently manages with spreadsheets and Word documents moves into DXMachine. The MITA SS-A gets produced as a live query rather than an annual assembly project. Provider enrollment, prior auth, program integrity, eligibility coordination — all running in DXMachine, all producing audit trails, all capturing the institutional knowledge that is currently distributed across the minds of people who are about to retire.
The mainframe processes claims and evaluates eligibility exactly as it always has. DXMachine does not touch those systems yet. It coordinates the workflow around their outputs and builds the documented record of what every process does, step by step. That documentation is the foundation the next phase requires.
Where the legacy system exposes a service boundary — an API-callable rules engine, a claims adjudication interface that accepts inputs and returns determinations — DXMachine agents sit above that boundary as workflow orchestrators. The legacy engine evaluates. The agent assembles inputs, invokes the engine, routes on the result, and produces the audit trail. Both systems run the same workflows on real data simultaneously.
Where no service boundary exists, DXMachine builds the equivalent logic in parallel — documented, tested against the legacy system's outputs, validated against real claims and real eligibility determinations. Discrepancies between the two systems are surfaced, investigated, and resolved. Every resolved discrepancy is a workflow fully understood and fully covered.
The APD documentation for this phase writes itself from Phase 1 evidence. The state can demonstrate to CMS exactly what MITA maturity level each process has reached, with continuous audit trail evidence rather than a consultant's assessment. The 90/10 federal matching funds follow the documented maturity improvement.
When Phase 2 parallel execution has validated every workflow the legacy system runs, the decommissioning decision is not a leap of faith. It is a documented conclusion. Every workflow is covered. Every edge case is resolved. The CMS-approvable audit trail of the transition exists as a native output of the parallel run — not assembled retrospectively by a consulting team, produced continuously during the migration itself.
The institutional knowledge that was walking out the door with retiring mainframe administrators is now encoded in the workflow definitions, the agent capability manifests, the execution records, and the audit trail that DXMachine produced during Phase 1 and Phase 2. It does not leave when the last COBOL programmer retires. It is in the system.
"The mainframe gets decommissioned when it has nothing left to do that DXMachine isn't already doing better — and when that proof has been built, workflow by workflow, on real data, in parallel, with a continuous audit trail that CMS can examine."
Every state Medicaid agency must produce a MITA State Self-Assessment — a documented maturity rating across roughly 90 business processes — as a condition of accessing 90/10 federal matching funds for MMIS investment. The SS-A is currently produced manually, documented in Word and spreadsheets, assessed against a checklist, and filed. It is a compliance ritual. DXMachine makes it a live query against actual workflow state.
The MITA maturity model runs Level 1 through Level 5. Level 1 is paper and manual. Level 5 is self-monitoring, optimized, real-time. The gap between what states document in their SS-A and what their systems actually deliver has been a known problem for two decades — the assessment became a documentation exercise rather than a genuine capability measurement. The person filling out the form learned the language. The system behind the form did not change.
The MMIS replacement vendors — Gainwell, Conduent, DXC — are competing for the Phase 3 contract: the full mainframe replacement, nine figures, decade timeline. Nobody is selling the state Medicaid IT director a platform that starts in Phase 1, builds the proof of coverage through Phase 2, and makes Phase 3 tractable for the first time. That gap is DXMachine's entry point — and it is open at all fifty state agencies simultaneously.
The funding mechanism already exists. The platform to justify it does not. That is the market position. Fifty accounts, federally co-funded, with an incumbent vendor landscape that is positioned for a conversation DXMachine is not having — and completely unprepared for the conversation DXMachine is.
The M2 advisory seat is looking for someone with direct operational experience inside a state Medicaid IT program or a major MMIS implementer — not at the executive or policy level, but at the level where systems either worked or didn't and someone was accountable for the difference. The three-phase arc is not a theoretical framework. It requires an advisor who has navigated the APD process, managed a parallel run, and understands where the institutional knowledge gaps are in a real MMIS environment.
Full advisory board description — all seven seats across both boards — on the Advisory Board page.
No pitch deck. No NDAs on first contact. A direct conversation about the domain, the three-phase arc, and whether there is genuine fit for the advisory seat or a design partner relationship.