Case study

Recovering a lost Dynamics 365 integration

When the only copy left was the one running in production.

The challenge

A Windows service had been importing Epicor master data into Dynamics 365 every day for years: five feeds, 52,042 rows a run, creating and updating customers, contacts, opportunities, price lists and part cross-references.

The source code was gone. What remained was a compiled assembly on a production server, no version control, and no documentation. Nobody could change it, nobody could test it, and nobody could say with confidence what it did to the data each night. It had simply kept running.

The business was also moving Dynamics from on-premises to online. The service authenticated through a retired library, rebuilt its connection on a timer, and had no handling for the request limits the online platform enforces. It was not going to survive the move, and there was no source to change.

What we did

Recovered the source. Decompiled the production assembly and cleaned it up by hand: one public type per file, every app setting read in one place, every Dataverse field name collected into schema classes. The cleanup was behaviour-preserving, and the result builds from source again.
Wrote down what it actually does. Not what anyone remembered it doing: a behavioural specification read out of the working code, feed by feed, including the business rules nobody had written down and the ones that turned out to be accidents.
Built a test suite that needs no CRM org. 207 tests running entirely offline against an in-memory Dataverse, and against the real production exports rather than handmade fixtures. Two silent mapping failures showed up only because the tests ran on real data.
Fixed what the recovery exposed. Twenty defects in the shipped assembly, each corrected with a comment at the line saying what the original did, so every change can be reviewed or reverted.
Proved every fix. Each one was reverted, one at a time, to confirm the suite caught it. That exposed three tests that had been passing for the wrong reason and covered nothing at all.
Modernized it for Dynamics 365 Online. Current Dataverse client, MSAL in place of the retired authentication library, service protection retries turned on, and a connection leak removed.

Results

20defects found and fixed in code that had run in production for years

207automated tests, offline, against 52,042 rows of real production data

113Dataverse field names verified against the SDK's own type definitions

5feeds documented end to end, from CSV column to Dataverse column

2build-time checks that fail a release on stale documentation or a log line that goes nowhere

The 113 field names are strings the compiler never checks and no test can cover, so they were verified against the SDK's own definitions. The documentation covers the rules nobody had written down.

Seven of the twenty defects were silent. They dropped or corrupted data and reported success: every contact email address discarded on import, one of two changed dates ignored, and a single re-sent row renaming every cross-reference in the system. None of them had ever produced an error, and none would have been found by reading the code.

Why it matters

Lost source is usually discovered at the worst moment: when a platform migration, an integration change or a failed run forces someone to open code that nobody can open. The instinct is to rewrite. That trades a system you cannot change for one you cannot trust, and it throws away years of business rules that exist only in the compiled code.

This is the approach behind every Plugin Rescue recovery: get the source back, write down what it does today, prove it with tests that run without touching your production system, then fix what the proof exposes, and show the difference, line by line.

Running something nobody has the source to?

Book a free 30-minute consult. We'll tell you what we'd look at first, whether or not you hire us.

Book a free consult More case studies