What we learned from the NRS TaxPro → Rev360 cutover
Eight weeks. 2.84 million taxpayer records. Forty-seven naming-collision bugs caught in pre-cutover reconciliation that would have shipped to production. The post-mortem, with timeline, agent decisions, and the three things we'd do differently.
The Nigerian Revenue Service migration from TaxPro Max to Rev360 wasn't supposed to be a story. The two systems had been running in parallel for nearly a year. The vendor had run sample reconciliations against extracted data. Every functional test had passed.
Then two weeks before the planned cutover, NRS's reconciliation team flagged something strange in our daily diff report: 47,000 taxpayer records were appearing as duplicates in the destination. Same TIN, slightly different names. Some had two records. Some had three. The kind of bug that doesn't show up in a sample because samples are too small.
The numbers
- ●2.84 million taxpayer records reconciled in production
- ●99.87% exact match on first reconciliation pass
- ●47,238 entity-collision anomalies surfaced by the Naming Library
- ●3,617 automatic resolutions; 12 escalations to the war room
- ●One weekend cutover window; zero rollbacks
The bug class — and why dev environments don't catch it
The pattern was always the same. TaxPro Max stored taxpayer names in shouty caps with aggressive abbreviation: ADEBAYO ENT., BANK OF AMERICA NIG. LTD, OKONKWO & SONS. Rev360 stored them title-cased and expanded: Adebayo Enterprises, Bank of America Nigeria, Okonkwo and Sons.
When Rev360's unique constraint on (tin, normalized_name) saw the second payment arrive against TIN 14729583012 with the name Adebayo Enterprises, it created a new entity row — because to its constraint, ADEBAYO ENT. and Adebayo Enterprises are different strings. The first payment had landed against the TaxPro-formatted name; the second landed against the Rev360-formatted name. Same taxpayer, two ledger entries, two outstanding balances.
The lesson — Reconciliation that compares exact-match strings on key fields is theatre. You need a Naming Library agent that knows the source's tokenization rules, the target's normalization rules, and the high-confidence equivalence pairs your specific industry uses. We had three of those built into the agent on day one. They caught all 47,000.
Timeline
Day 1 (Mar 18) — Migratio's Schema Mapper ingested both schemas and proposed 47 field mappings. 38 high-confidence direct mappings. 4 transformations (date formats, code lookups). 3 low-confidence requiring review. 2 unmapped (taxpayer status flags with no clear target field — escalated).
Day 3 — First reconciliation pass against a redacted 10,000-row sample. 99.94% match. Three anomalies, all surfaced and explained by the Reconciliation Agent. NRS's compliance team signed off the sample run.
Day 14 — First full extract: 2.84M taxpayer master records, 4.1M payment records. Reconciliation pass against full dataset: 47,238 anomalies. The Naming Library auto-resolved 3,617 high-confidence equivalences. The rest sat in Exception Triage for human review.
Day 21 — The 12 most senior anomalies got walked through with NRS's leadership. One was particularly thorny: a federal contractor whose corporate hierarchy had restructured during the migration window and now resolved to a different parent entity in Rev360. That decision needed a sign-off from the taxpayer's own legal team. We escalated, waited, and resolved in 9 days.
Day 56 — Cutover weekend. War room: 4 people on the call, 2 on-call backup. We watched the live reconciliation rate climb toward 99.87% as records flowed. The 0.13% gap was exactly the 12 escalations still pending — known and accounted for in our cutover plan.
Three things we'd do differently
1. Run a sample reconciliation in week two, not week six
We could have caught the naming-collision class on a 10K-row sample in the first month. We didn't, because we trusted the vendor's compatibility statement. Sample early, even when you don't think you need to. The 47K anomalies took 6 weeks to work through — that's 6 weeks we could have started earlier.
2. Get the Naming Library curated by the customer's compliance team, not us
Migratio's Naming Library ships with sane defaults: standard suffix normalization (Ltd / Limited / LTD), common abbreviation expansion, case folding. But each customer has institutional knowledge about their data that no platform default captures. For NRS, "Co-op" and "Cooperative" aren't always equivalent — some are federally registered, some aren't. That kind of knowledge has to come from the customer.
3. Budget for a 9-day legal escalation slot
The federal contractor restructuring isn't unique. In any migration of this size, there will be 5–20 records that can't be resolved by either platform or vendor — they need the taxpayer's own team to confirm. Don't put those in the critical path. Identify them in week 3, escalate in week 4, expect resolution by week 9.
What's in the post-mortem doc
The full internal post-mortem is 47 pages. The redacted external version we share with similar customers covers: cutover war-room playbook, the exact Naming Library rule set we shipped, the 12 escalation records (anonymized), the Schema Mapper confidence-score breakdown, and the dataset of every auto-resolved entity collision.
If you're considering Migratio for a tax-authority or core-banking migration in the next 12 months, ask for it on your discovery call. It's the most concrete thing we can give you to evaluate whether we'll be useful.
