The model moves, the platform does not
Most companies replace their CRM every seven to ten years. The way they decided to represent a customer tends to survive all of it. The replacement gets shaped around the data arriving from the system it replaces, because a migration is judged on whether records land, not on whether the shape they land in still makes sense.
I have sat through three of these in four years. Each time the modelling workshop ran two days and the field mapping ran four months. Nobody in the mapping sessions had the standing to say that an account should have been two accounts, so the mapping preserved what was there.
A modelling decision changes what a record means and how many records exist. A configuration choice changes how a record is presented, validated or routed. The first one migrates whether you want it to or not. The second gets rebuilt from scratch every time, and rebuilding it is the cheap part of the project.
What counts as one account
The hardest version shows up when the same company buys through three subsidiaries. Procurement sits in one legal entity, another signs the contract, and the people who use the product report to a third. Sales wants one account so the rep sees the whole relationship. Finance wants three, because three entities pay invoices under three tax registrations.
A European manufacturer I worked with three years ago had an account hierarchy four levels deep with no consistent rule behind any level. Their first CRM, retired in 2014, could not do hierarchies at all, so the team faked one by creating a parent record for every sales region and hanging the legal entities underneath. Those regional parents were never customers.
Two CRM generations later, those parents had account managers, open opportunities and support entitlements attached. Reporting rolled up through them. Nobody could remove them because too much hung off them, and nobody could defend them because the reason had retired with the first system. We kept them and wrote the history down, which is not a fix, though it stopped the next team inventing a worse explanation.
Settle the rule once, in a sentence a finance controller and a sales director both sign. An account is a party that can sign a contract, and anything above it is a grouping that owns nothing. Then give each account an identifier that survives the next migration, the same discipline as the field guide to durable business keys.
The contact who changes jobs
The contact record is where most models quietly pick a side. If a contact belongs to a company, a person who moves employer becomes either a second record or an overwritten one. If a contact belongs to a person, the employer becomes a dated relationship, and the same human can hold two of them during a handover month.
The first shape costs less on day one and most vendors ship it by default. You pay later, when the rep who spent four years earning a buyer's trust cannot find her at the new company, because the email bounced and the record went stale in an account nobody covers any more.
You do not need a full party model to fix this. You need a stable identifier for the human that is independent of the employment, plus a relationship record carrying a start date and an end date. That much migrates. How the new employer gets suggested in the interface will be rebuilt anyway. It is the same argument as what a shared customer record really needs across systems, applied inside a single one.
Relationships with no obvious parent
Hierarchies assume a parent. Plenty of real commercial relationships have none. A reseller sells your product to an end customer you also sell to directly. A joint venture is owned by two accounts that compete everywhere else. A hospital group and a purchasing consortium overlap in membership that changes every year, and neither one owns the other.
Forced into a hierarchy, these make somebody pick a parent that is not true, and the pick sticks for a decade. Held in a relationship record with two account references, a type and a date range, they cross a migration intact, because the next system can read them without guessing what the nesting meant.
The question to settle is whether the relationship carries anything of its own. If it has a start date, an owner or a revenue share, it is an object, and the reasoning matches the one about whether something deserves its own table. If it is only a label hanging off one of the two accounts, a field will do.
What a product is when finance disagrees
Sales counts what it sells. Finance counts what it recognises. Those are rarely the same object. A three-year subscription with an implementation fee and a support tier is one line on a quote and several streams in the ledger, and a model holding only the quote line loses the rest the first time somebody asks for renewal reporting.
The durable decision is the grain, meaning the smallest thing that can carry its own price and its own renewal date. If sales and revenue accounting answer that differently, you have two objects and a mapping, and the mapping belongs in the model rather than in a spreadsheet somebody maintains by hand. It is the same fight as who gets to define revenue, one level down.
Catalogue structure is the opposite. Families, bundles and display groupings are presentation, and whoever owns the catalogue next will redraw them within a quarter. Spend the argument on the grain and let the categories be someone else's afternoon.
Where the deal history goes
Deals change shape mid-cycle. Two opportunities merge because the customer decided to buy everything at once. One splits because legal insisted on contracting per country. A stage moves backwards after a champion leaves. What the model does with those events decides whether anyone can answer a question about last year.
Keeping only the current state is the default, and it quietly ruins any later attempt to measure forecast accuracy. Keeping a full event history is expensive and most teams never read it. What has held up best for me is a dated snapshot of the fields that drive money, written whenever one changes, plus explicit links recording that this opportunity came from those two.
Those links are the part people forget. Without them a merged deal reads as two losses and one unexplained new opportunity, and the win rate on the quarterly report is wrong in a direction nobody can account for. The snapshots migrate. The dashboard built on top of them does not.
The test to run before the month-long argument
Here is the test I use at the whiteboard. Write the decision down, then ask whether reversing it in two years means changing records or changing settings. Changing records means a backfill and a reconciliation nobody budgeted for. Changing settings means an afternoon. Record surgery is structural. Settings are cosmetic, however loudly the room argues about them.
The longer version asks what a competent consultant would do with the decision five years from now, with nobody left to explain it. If they would have to preserve it because the data cannot be read without it, it is structural and deserves the month. If they would rebuild it to match the new platform's conventions, it is cosmetic. Page layouts, validation rules and the lead routing rules that stop making sense all fail that test.
Open your own model this week and find the three decisions that would survive a replacement. Then find out who made them and whether that person still works there. In most companies the answer to the second question is no, which is exactly why the first question is worth an hour of somebody's Thursday.
