How we think about the work.

Your data is the implementation. Everything else is configuration.

Ask any experienced ERP consultant where implementations most commonly go wrong, and the answer is rarely the software. It's not the project plan, the vendor, or even the change management program. It's the data. Specifically: the decision — made early, often casually — to migrate existing data into a new system without first asking whether that data is worth migrating at all.

The consequences compound quietly. Duplicate customer records proliferate. Inventory valuations carry forward assumptions that no longer reflect reality. Chart of accounts structures built for a business that no longer exists get mapped into a platform that was supposed to fix all of that. By go-live, the shiny new ERP is running on the same dirty foundation the old one was. Six months later, leadership wonders why nothing actually changed.

The audit phase almost nobody does properly

A serious data migration begins not with extraction but with interrogation. Before a single record is touched, the right questions are: What data do we actually need in the new system to run the business on day one? What do we need for historical reference but not active use? And what can we retire entirely? These are business questions, not technical ones, and they need business owners in the room to answer them — not just IT.

This audit typically surfaces more than expected. Vendor records that haven't been touched in years. Product catalog entries for items that were discontinued before most of the current team was hired. Customer accounts that belong to contacts who no longer exist. Every one of these represents a decision: migrate it, archive it, or cut it. The instinct is to keep everything. The discipline is to keep only what earns its place.

Mapping is where strategy becomes structure

Once the audit is complete, the migration mapping process translates the current data model into the new system's structure. This is where technical complexity meets business logic — and where the two must be reconciled deliberately rather than assumed to align.

Common failure points here include:

• Account code mapping done by accountants without developer input, resulting in structures the system can't report on correctly.
• Product attribute mapping done by IT without operations input, resulting in a catalog that looks correct but doesn't support manufacturing BOMs or pricing logic as intended.
• Open transaction migration without cutover alignment, where AR and AP balances move without agreement on the cutover date, creating reconciliation nightmares that take weeks to unwind.

Every one of these is predictable. Every one of them is preventable with a mapping process that involves the right people at the right time.

Validation is not a QA step — it's a business sign-off

A common mistake is treating data validation as a technical checklist: row counts match, foreign keys resolve, no null values where nulls aren't permitted. These checks matter. But they are not the same as business validation, which asks a different question entirely: does this data accurately represent the state of our business as of the cutover date?

Business validation means a warehouse manager confirms that the inventory quantities in the new system match what's physically on the shelves. It means a finance lead reconciles the opening balances against the last close. It means an operations lead spot-checks a sample of active work orders and confirms the data looks right. This takes time. It sometimes surfaces problems that require re-migration. And it is non-negotiable, because the alternative is discovering those problems after go-live — when the cost of fixing them is orders of magnitude higher.

What a good migration strategy actually looks like

The migrations we're most proud of share a few characteristics. They started earlier than the client expected — typically in the first weeks of the engagement, not as a late-stage activity. They involved business stakeholders in decisions that looked like technical ones, because those decisions have business consequences. They included at least one mock migration before the real one, so surprises surfaced in a controlled environment rather than on cutover weekend. And they treated the cutover plan as a shared document that every team lead had reviewed and signed off on, not a project manager's artifact.

None of this is exotic. It's discipline applied consistently to a phase of the project that too many firms treat as a box to check rather than a foundation to build.

Your new ERP will run as well as the data you put into it. That means the migration strategy is not a migration question. It's an implementation question. Treat it accordingly from day one.

The knowledge problem in ERP consulting — and how to solve it.

There is a failure mode in complex ERP implementations that almost never appears on a project status report. It doesn't show up as a red RAG rating or a missed milestone. It accumulates invisibly, across weeks and months, and it only becomes visible when something goes wrong in production and nobody can explain why a particular decision was made six months ago — or even who made it.

The failure mode is context loss. And it is, in our view, one of the most underappreciated sources of implementation risk in the industry.

What context loss looks like in practice

Every complex ERP implementation moves through distinct phases: discovery, solution design, build, testing, training, go-live, and hypercare. In the traditional consulting model, these phases are often staffed differently. The senior consultants who ran discovery are largely unavailable by the time testing begins. The business analyst who documented the requirements has rolled off the project. The developer who built the custom workflow never sat in the original process workshops.

What gets lost in these transitions is not documented anywhere, because it was never captured to begin with. It lives in the memory of the people who were in the room — the informal constraints, the contested decisions, the rationale that was debated and resolved over three hours in a conference room and then summarized in two lines of meeting notes. When those people leave the project, that reasoning leaves with them.

The downstream effects are real. A tester encounters behavior in the system that doesn't match their expectation and logs a defect — not knowing that the behavior was intentional, the result of a specific client constraint discussed in week two of discovery. A trainer explains a workflow to end users and gets it slightly wrong, because the nuance of why it works that way wasn't in the training documentation. A post-go-live support request opens a discussion that rehashes an argument that was already resolved, because nobody remembers the resolution.

Why the problem is structural, not personal

It's tempting to frame this as a documentation problem. Document better, and the context won't be lost. In practice, this is only partially true. The real issue is that the kind of context that matters most — the reasoning behind decisions, not just the decisions themselves — is extraordinarily difficult to capture in the formats traditional project documentation uses. A requirement specification can tell you what a process does. It rarely explains why it was designed that way, what alternatives were considered, or what business constraint ruled those alternatives out.

The problem is structural because it's a consequence of how traditional consulting engagements are organized: phased delivery, rotating teams, and a documentation culture oriented toward defensibility rather than continuity. These aren't failures of individual consultants. They're characteristics of a delivery model that was designed before the tools existed to do it differently.

Carrying context as a first-class deliverable

Our approach treats context as something to be actively maintained throughout an engagement, not reconstructed from artifacts after the fact. This means a few specific things in practice.

First, discovery output isn't just a requirements document — it's a living knowledge base that captures the business reasoning behind each requirement, the options that were evaluated, and the rationale for what was chosen. This isn't a document someone reads once and files. It's a resource that the entire team actively references throughout the engagement.

Second, we use shared AI-native context environments that allow the full project team — consultants, developers, and client stakeholders — to query the accumulated context of the engagement in natural language. When a developer asks why a particular workflow is configured the way it is, they get an answer grounded in the actual discussion from discovery, not a guess or a shrug.

Third, we staff engagements with continuity in mind. The people who understood the problem at the start are present when the solution is being tested. This is partly a team structure decision and partly a function of scale — a deliberate choice to work with a small number of clients at a time rather than spreading thin across a large portfolio.

The compounding advantage

The value of carrying context compounds over the life of an engagement. In the early phases, it prevents re-litigation of settled decisions. In testing, it turns potential defects into confirmations of intentional behavior. In training, it gives trainers the ability to explain not just how the system works but why it was built that way — which is what makes training actually stick.

After go-live, it pays the longest dividend. When a user raises a question about system behavior six months in, the answer doesn't require a forensic investigation. It's documented, accessible, and traceable to the original conversation. That's not just efficient. It's the difference between a client who trusts their system and one who is perpetually uncertain about it.

Context is not a nice-to-have on a complex implementation. It's the connective tissue that holds everything together. Treating it as such from day one is one of the highest-leverage changes an implementation methodology can make.

Time and materials is a tax on good work. Here's what replaces it.

The time-and-materials billing model has been the default in consulting for so long that it has started to feel like a law of nature. You engage a firm. They estimate hours. They bill those hours. You pay. The engagement ends when the budget runs out or the scope is complete, whichever comes second.

Everyone in the industry knows the structural problems with this model. It creates incentives that are misaligned with client outcomes — a firm billing by the hour has no financial motivation to work efficiently, and a client paying by the hour has no reliable way to know whether the hours being billed represent good work or slow work. The model commoditizes consulting by making price the primary competitive lever, which drives firms toward offshore delivery and junior staffing as margin protection strategies. And it prevents the kind of long-term thinking that leads to genuinely transformative engagements, because every conversation about scope is filtered through the anxiety of what it will cost.

The interesting question isn't whether T&M is broken — most people who've worked on both sides of an engagement already know it is. The interesting question is what actually replaces it.

What value-based pricing is, and isn't

Value-based pricing is sometimes described as if it were simply a matter of charging more. That's a misunderstanding. Value-based pricing is a different philosophy of what the engagement is for. In a T&M model, the deliverable is hours of consulting work. In a value-based model, the deliverable is an outcome — and the price is set in relation to the value of that outcome, not the cost of producing it.

This distinction has real consequences. It means that before an engagement begins, both parties need to agree on what success looks like and why it matters financially. A manufacturer that reduces its month-end close from three weeks to five days has received something with a calculable value. An industrial distributor that achieves real-time inventory visibility across six locations has reduced carrying costs in a way that can be estimated with reasonable confidence. These outcomes don't require precise measurement to be priced against — they require honest conversation and a shared willingness to connect the consulting work to the business result it's intended to produce.

The three conditions that make it work

Value-based pricing isn't viable in every engagement. It works reliably when three conditions are present.

• The outcome is well-defined. Both parties need to be able to describe, in specific terms, what a successful engagement looks like. "Better operations" is not an outcome. "Inventory accuracy above 98% within 90 days of go-live" is. The more precisely the outcome is defined, the more straightforwardly the price can be set against it.
• The consulting firm has genuine accountability for delivery. Value-based pricing only works if the firm carrying the risk also carries the authority to execute. A firm that prices on value but then has its recommendations overridden at every turn has the structure of a value-based engagement with the dynamics of a staff augmentation. The client must be willing to extend real decision-making authority on the implementation, and the firm must be willing to accept real accountability for the result.
• There is alignment on the client's capacity to participate. Value-based engagements move faster and require more from client stakeholders than T&M engagements typically do. A client who cannot get subject matter experts in the room, cannot make timely decisions, or is not organizationally committed to the change being implemented will struggle to realize the value that was priced into the engagement — and frustration follows on both sides.

What next-wave consultancies are getting right

The firms rethinking this model aren't doing it purely for philosophical reasons. They're doing it because it's the right commercial structure for a world where the quality gap between good and mediocre consulting has widened substantially — and where clients who've lived through failed T&M implementations are increasingly willing to pay a premium for accountability.

The best of these firms are combining value-based pricing with two structural changes that make it sustainable. First, AI-native delivery methodology that compresses the time and resources required to produce high-quality outcomes — which means the value captured doesn't have to come entirely at the expense of margin. Second, a deliberate limitation on engagement volume, so that the firm's senior people are genuinely present and invested in every client relationship rather than spread across a portfolio of undifferentiated accounts.

The economics are compelling. A firm doing ten $150K T&M engagements per year, staffed primarily with mid-level consultants and managed by a senior partner who is present at the beginning and end, is running a fundamentally different business than a firm doing four $400K value-based engagements per year, where senior people are present throughout and outcomes are explicitly contracted. The revenue difference is significant. The difference in client experience is larger still.

The conversation the industry needs to have

Moving toward value-based pricing requires consulting firms to have a harder conversation with themselves before they have it with clients. It requires honest self-assessment of whether the outcomes they're promising are ones they can actually deliver — not in a favorable environment with a cooperative client, but reliably, across different industries and organizational maturity levels. Firms that can't answer that question confidently shouldn't be pricing on value. The accountability is real, and it should be.

For the firms that can, the shift represents something more than a pricing change. It's a statement about what kind of business they're building: one where the client's success and the firm's success are structurally the same thing, rather than structurally in tension. That alignment changes everything about how an engagement runs, from the first conversation to the final deliverable.

T&M will persist for years in certain contexts — staff augmentation, small-scope fixes, and engagements where outcomes genuinely can't be defined in advance. But as a default model for transformational consulting work, its limitations are too fundamental to paper over. The next wave of consultancies isn't waiting for the industry to catch up. They're building around a different set of assumptions from the start.