The week the renewal report went missing

A month after a Dynamics 365 Sales org moved onto Sales Cloud, the regional director for the north asked why her renewal list showed sixty accounts instead of the ninety she had worked all year. The load had reported success. Every row the team asked for had arrived.

The accounts were all there. A deduplication rule matching on company name and postcode had folded each customer's trading entities into their parent, pushing the renewals to an owner two levels up. Nobody reviewed the merge output, because the merge ran inside the load and the load had no errors.

Unwinding it took six weeks and a read-only restore of the source, which still existed because one architect had argued to keep it. The damage came out of a twenty minute call about matching thresholds, squeezed between two longer conversations about field mapping.

What comes across is the decision you keep postponing

The first decision a migration hands you is which records move at all, and it shapes the result more than every mapping rule that follows. It is also the one teams defer longest, usually until the extract is written and changing scope means changing code and dates.

A migration is the only realistic chance anyone gets to leave data behind. Once records land in the new system they are somebody's history and they appear in somebody's report, so removing them means winning an argument. Before the move, nothing has to be deleted. Records stay in the source and stop being carried forward.

The useful question is not whether data is old but whether anyone will act on it. Closed opportunities from eight years ago can earn their place, because analytics can use them to say which deals your company wins. Contacts nobody has called since then cannot, and they degrade search for every user for a decade.

Make the call explicitly with the business, name who signs it, and write down what stays behind. Then be honest about what normally happens. Teams bring everything, because nobody wants to be the person who dropped the records the finance director later asks for, and because defending an exclusion costs more than moving the rows.

Merging is permanent even where it is reversible

Deduplication is where careful people get overconfident. Most platforms describe merges as reversible, and in a narrow technical sense some are. Nobody unwinds a merge three months later, because the surviving record now carries new activity, new opportunities and edited values, with no honest way to say which belonged to which original.

So the matching rules deserve more scrutiny than any other rule in the project. Run them against a copy, export the list of what they would merge, and read the first two hundred rows yourself. Where both systems hold a business key the company already reads out loud, use it and stop scoring names.

Three cases deserve test records before anyone argues about thresholds. The same company recorded twice with different spellings, where one row says Nortons Ltd and another says Norton's Limited at one address, and a tight rule leaves both. Next, two unrelated firms that share the name Apex Services, where a loose rule welds them together along with their contracts.

Then the person who exists at two employers, where one name and mobile number sit under an old account and a new one, and merging the contacts moves five years of activity to a company she left in March. Have someone from sales read the merge list first. They recognise the customers, and the argument settles by lunchtime.

The target's validation never met the old data

Validation in the new system was written for records the new system creates. Your old records came from different rules, sometimes from none, and plenty are illegal in the target the moment they arrive. A required industry value, an email format check, a lookup that has to point at an active record. Each rejects rows the source held happily for fifteen years.

Somebody has to decide, field by field, between three answers. Relax the rule, and the new system starts with the tolerance of the old one. Populate a placeholder, and the record loads while the rule survives. Or exclude the failing records and leave them behind with everything else you agreed not to move.

Placeholder values entered during a migration outlive everyone who remembers what they meant. Five years on, one report filters out an industry called Unknown and another groups by it. The honest answer is that a load job needed a value in that column one night in 2026. Use one placeholder string, put it in the data dictionary, and make somebody report the count down.

The change to resist is the validation loosened at eleven at night because a load failed and the window closes at six. Rules relaxed under deadline pressure never get tightened again.

Owners who left and picklist values that do not exist

Every record points at things outside itself, and each broken reference needs a decision. Owners who left two reorganisations ago. Territories merged last April. Campaigns deleted in the source that still sit in a lookup on ten thousand contacts.

Ownership is what users notice on day one. Assigning every orphaned record to the migration service account is fast and wrong by the first pipeline review, because nothing appears in anyone's list. Assigning by current territory takes a mapping table sales operations can produce in a morning. Decide before the load. Reassigning two hundred thousand records afterwards costs a weekend and a lot of goodwill.

Picklist values are quieter, and they decide what reporting is possible for years. The source has nineteen lead sources, the target design has seven, so twelve get mapped into a surviving option or into Other. Anyone asking how many deals came from the old partner programme finds the answer folded into Other with no route back.

Run the value mapping past whoever builds the reports before the design is signed off. They will ask to keep three of the twelve, a cheap argument now and an impossible one in eighteen months. Analytics questions belong in the requirements next to the field list, for exactly this reason.

A row count proves nothing

The standard verification compares source rows against target rows and proves that a quantity of records arrived. It says nothing about whether the right records arrived, whether they kept their relationships, or whether anyone can report on them afterwards.

Start with totals the business already publishes. Open pipeline by region this quarter. Accounts with an active contract. Cases opened last month. People have seen these numbers and will argue about them, which makes them useful, and a metric nobody can reproduce twice is the last thing a migration should create.

Then check a sample end to end rather than field by field. Take ten accounts per segment and follow each through its contacts, its open and closed opportunities, its attachments and its owner. Field comparison finds mapping errors. Record by record review finds missing children, activity on the wrong parent and the merge that moved a customer's history.

Above all, put real users in front of their own records a week before cutover, which is what a proper migration rehearsal makes room for. A sales manager reading her own twelve accounts will tell you in seconds that the number is the old switchboard and one of them closed in March.

  • Reconcile one total the business already publishes, such as open pipeline by region this quarter.
  • Follow ten records per object end to end, including their children, attachments and owners.
  • Check that merged records kept the earliest created date and the owner the business expects.
  • Rebuild the three reports leadership opens on a Monday and compare them with last month's saved copies.
  • Give twenty named users their own records to review in the target, a week before cutover.
  • Keep a written list of every record class left behind, with the name of whoever agreed it.

Take the scope question into this week

If you have been handed a migration and a date, book one meeting this week with the person who owns the CRM budget and a sales leader who lives in the system. Bring a page of record types with volumes and last-touched dates, and have them mark each line move, move for analysis, or leave behind.

Everything else in the project can be repaired after go-live for money. What you leave behind is the only part that gets harder every week you wait, and it will never be as easy to settle as it is now, with nothing loaded yet.