Reporting that told the truth daily
Progress was tracked against a fixed baseline and reported daily, not weekly and not narratively. Every work item carried a release tag, so scope movement was visible the day it happened rather than at the end of a sprint. On a fixed-date program, the expensive discoveries are the late ones.
A gated cutover
Production migration ran as a sequenced set of gates, each one a precondition for the next. Environment preparation, configuration and data load, technical validation, business validation, then release. Data freeze, code freeze, reconciliation sign-off and business sign-off all landed in the same week, in order. Every gate landed on the day it was planned for.
One team, three organizations
Myridius led as prime systems integrator, accountable for the whole program including the parts other organizations delivered. Origami Risk provided platform architecture, design review and technical consulting. The client embedded business and underwriting decision-makers directly into the delivery cadence. On a compressed program, a client’s response time is a delivery constraint exactly like developer capacity.
What went live: policy administration across eight states
The complete policy transaction lifecycle went live, not a renewal-only slice. Every transaction runs through the full path, from submission and application through quote, bind and issue, and then through servicing across the life of the policy. Eight states, seven transaction types, 56 state-transaction configurations.
| Capability |
What it covers |
| Policy administration |
Complete policy lifecycle: application through quote, bind, policy servicing, cancellation and renewal |
| Rating and underwriting |
Workers Compensation product configuration: payroll, experience modification, schedule rating, deductibles and underwriting referrals |
| Billing |
Policy-to-payment processing: billing plans, invoices, premium categories and payment allocation |
| Data conversion |
The acquired book and its history: insureds, policies, transactions, billing records and documents |
| Documents and operations |
The operational layer: forms, emails, reports, dashboards, general ledger, mailing and IVANS |
| Reporting |
Regulatory and statistical: state and bureau reporting data, delivered from the same platform that writes the business |
Moving five years of policy history: the insurance data conversion
Data conversion was not a file transfer. The team had to define the correct policy population, preserve the relationships among accounts and insureds, reconstruct rating and coverage detail, and carry billing and payment history into the new platform. Operational history, not a static archive.
1. Define the final book
The final extract covered policy years 2022 to 2026 across two underwriting funds. 2,995 flat-cancel and zero-cost shell records were deliberately excluded, so the converted book started clean.
2. Rebuild account and policy relationships
Policies were connected to the appropriate insured accounts and member-master records, so the converted book retained its operational structure rather than arriving as a flat list.
3. Restore underwriting and rating detail
The conversion carried forward the exposure, rating and coverage attributes required to understand and service each policy, not merely its header information.
108,788 payroll class-code records · 67,573 experience-modifier records · 14,217 waiver-of-subrogation records · 12,356 schedule-rating records · 176,407 owner and officer records · 14,660 work locations
4. Carry forward financial history
Premium, billing and payment records were migrated onto their appropriate ledgers, so the new platform began with usable financial history from its first day.
$679.7M converted premium · 233,144 billing line items · $98.1M billed value · 389,483 payment transactions · $270.3M payment value
All figures reflect the final production extract and exclude flat-cancel and zero-cost shell records. Owner and officer records are maintained at a historical account-key level. Premium, billed value and payment value are different measures and should not be read as one reconciliation equation.
Testing at the speed of the calendar: AI-assisted test automation
A fixed date compresses the part of a program that usually flexes: testing. The team answered in two ways. User acceptance testing began roughly six weeks earlier than convention, running against components as they were completed rather than waiting for a finished system, which moved defect discovery forward instead of stacking it against the deadline. Alongside it, the team built AI-assisted test automation during the program rather than after it.
Built three times faster. 67% less engineering effort
AI-assisted engineering generated and refined automation code, built reusable utilities and supported debugging. Work estimated at 72 hours of traditional effort was completed in 24.
Recurring execution value. 87% faster per cycle, 13 defects found
Manual regression scenarios were converted into maintainable automated tests, reaching roughly 60% automation coverage of the targeted scope across regression, forms and smoke validation. A cycle that took 24 manual hours now runs in 3.2.
Built to keep its value. 2.8% maintenance ratio
AI-driven self-healing addresses the classic failure mode of test automation, which is maintenance cost. Early indicators show maintenance effort at roughly 2.8% of development effort across the 12 application pages covered so far.
Every subsequent release now inherits this suite. The execution savings recur with each cycle, without a corresponding increase in manual testing effort, which is what makes automation an investment rather than a cost.
The results of the policy administration implementation
Five results, each measured and defined.
| Six months |
From the engagement’s effective date to a production system, including the six-week blueprint phase. |
| Ninety-eight days of build |
From the first line of configuration to a working system carrying a converted book. |
| Zero days of slip |
The date the book required was the date the system arrived. Every cutover gate landed on its planned day. |
| $679.7M in premium converted |
47,064 policies across five policy years, with rating detail and financial history intact. |
| 56 state-transaction configurations |
Eight states, seven transaction types, each with its own statutory forms and rating rules. |
Before and after the policy administration migration
Every row below restates a change already described elsewhere in this case study.
| Operational area |
Before Myridius |
After Myridius |
| Policy administration |
Acquired book ran on a platform the client intended to exit |
Complete policy lifecycle on the client’s own platform, application through renewal |
| Renewal issuance |
Dependent on infrastructure outside the client’s control |
Renewals generated in-house against a fixed notice lead time |
| Policy history |
Five policy years held in the source system |
47,064 policies converted with rating, coverage and financial detail rebuilt |
| Regression testing |
24 manual hours per cycle |
3.2 hours per cycle at roughly 60% automation coverage of targeted scope |
| Test construction |
72 hours of traditional engineering effort |
24 hours with AI-assisted engineering, a 67% reduction |
| User acceptance testing |
Conventionally begins about two weeks before deployment |
Began roughly six weeks earlier, against components as they completed |
| Program reporting |
Conventional weekly, narrative status |
Daily reporting against a fixed baseline, every item release-tagged |
Why it worked
Three things, and only one of them is about technology.
The date was treated as real from day one. Not aspirational, not a stretch goal to be renegotiated in month four. Every scoping conversation started from a fixed endpoint and worked backwards, which is uncomfortable early and decisive late.
The client was part of the delivery team, not an audience for it. Questions came back the same day. Decisions were made rather than deferred. On a compressed program, a client’s response time is a delivery constraint exactly like developer capacity, and the client removed it as a constraint.
Scope honesty beat scope optimism. A defined Day 1, with everything else sequenced deliberately behind it, produced a complete working system on the date the business needed one. An ambitious Day 1 that arrived late and incomplete would have failed the only test that mattered.
What comes next
Phase 1 established the core: the policy transaction lifecycle, rating, billing and the converted book. Design work on the next phase began the week after go-live, running to a structured workshop series with the client.
- Portals and external experience. Agent and producer portal, insured and member portal.
- Payment integrations. Card and ACH gateway, lockbox check-payment feed, pay-as-you-go payroll integration.
- Commissions and billing communications. Configuration, disbursements, statements, billing correspondence.
- Product data and rating inputs. Class codes and NAICS-based business rules, experience modification data integration with NCCI, dividend plan, predictive model.
- Receivables controls. Holds and moratoriums, surcharge and tax separation, refunds, thresholds.
- Statutory lifecycle and operations. Statutory cancellation, renewal and non-renewal rules, premium audit, claims integration.
Scoping a first release honestly is what made the date achievable. Everything above was a decision, not an omission.
Frequently asked questions
Why could the go-live date not move?
Workers Compensation policies are annual contracts, and renewal notices carry a required advance lead time, which this client worked to a 60-day standard. Notices are produced in batch and posted physically, adding roughly two weeks. With renewals due to start in October, the system had to be live in the first week of August.
When was the deadline actually set?
Before the engagement began, during the negotiation phase. The date came from the acquired book’s renewal calendar rather than from a project plan, so it was an input to scoping rather than an output of it.
How was five years of history moved without losing rating detail?
Conversion rebuilt account and policy relationships, then restored the exposure, rating and coverage attributes required to service each policy, including 108,788 payroll class-code records, 67,573 experience-modifier records and 14,660 work locations. Premium, billing and payment history followed onto their appropriate ledgers.
How was testing handled on a compressed timeline?
Testing was parallelized rather than compressed. User acceptance testing began roughly six weeks earlier than convention. AI-assisted automation reduced test build effort by 67% and per-cycle execution time by 87%, with early maintenance effort at roughly 2.8% of development effort.
A date is a design constraint, not a deadline
Working to a date you cannot move? That is the situation we are built for. Tell us what the calendar says and we will tell you honestly what fits inside it.
This was not a faster project. It was a project designed around a date that was never in question.
What is next
If your calendar is set by an acquisition, a regulatory obligation or a contract you are exiting, Myridius can tell you what fits inside it before you commit.
Talk to a Myridius expert. Send us a message at Digital Transformation Solution Provider | Contact Myridius.
