Engagements

A complete inventory of the custom code around your ERP: every program, interface, and scheduled job, who understands each one, and what specifically stops working when they leave. Everything sorted into three buckets — customization you no longer need, business logic that is genuinely your advantage, and integration plumbing — because those deserve completely different treatment.

It also answers the question most technical assessments skip: whether the team you have can maintain, migrate, or operate the target state, and what it would take if not.

You end with a staged roadmap with cost and duration bands, and a three-page summary written for a CFO rather than an IT manager.

This is the right starting point for most engagements, and frequently the only one a company needs.

For when systems that should work together don’t: after an acquisition, when replacing something half the business depends on, when data moves between departments by spreadsheet, or when designing the integration layer for something new.

You get a current-state map of what actually talks to what and where the data diverges, a target architecture with an explicit statement of what each system owns, integration designs that specify failure and reconciliation behavior rather than just the happy path, and a cutover sequence that lets the business keep running.

This is the work I’ve been doing longest — 29 years of it, across industries.

Requirements defined from your actual code, not a wish-list workshop. A target reference architecture — where the ERP ends, where configuration lives, how engineering connects. Vendor evaluation scored against those requirements, including the questions buyers in this market usually don’t know to ask.

The recommendation comes with a dissent section: what would have to be true for the second choice to win. If a vendor I have any relationship with is a candidate, I disclose it in writing at the outset and recuse from scoring that category.

Your configuration and business rules pulled out of legacy code into a documented, testable specification — while the person who understands them is still on the payroll.

The deliverable isn’t a document you have to take on faith. Extracted rules are replayed against a year of your historical transactions, then reconciled line by line, so you receive a specification with a measured accuracy figure and a written explanation for every case that differs. Deterministic static analysis and data-table extraction do the structural work; AI assists with interpretation; validation against your own history is what makes the result trustworthy.

Valuable whether you migrate next year, in five years, or never.

Two modes, often running together.

Implementation oversight — an owner’s representative during an implementation someone else is running. I review the integrator’s design decisions against the requirements, attend steering meetings, and flag scope drift and deferred problems before they become go-live problems. Your implementation partner knows more about the project than you do; this closes that gap.

Technology leadership advisory — a standing relationship for an owner or executive with no CTO who doesn’t need a full-time one. Architecture review before commitments are made, succession and hiring planning for technical roles, vendor and contract sanity checks, and a second opinion available whenever something structural is being decided.