Salvage or Rebuild: Deciding What to Do With a Half-Finished Dynamics 365 Implementation

Why is the salvage or rebuild decision so hard to make on instinct?

Because both instincts are biased. The people who paid for the first attempt lean towards salvage, because writing off the spend feels like admitting the decision was wrong. The people who have to live with the system lean towards rebuild, because every problem they see looks like proof the whole thing is rotten. Neither view has read the environment.

An unfinished implementation also looks worse than a finished one of the same quality. Half-built forms, test records, abandoned tables and flows that were switched off mid-change sit alongside the parts that work, and users judge the system by the worst screen they have seen. The opposite trap is a polished demo area over a data model that cannot support the next phase.

The money already spent is not an argument either way. The only question is which route delivers the working system the business needs, at lower cost and lower risk, from where you stand today. That question has an answer, and it comes from evidence rather than opinion.

What assessment makes a salvage or rebuild decision defensible?

One that looks at the five dimensions below, records the evidence for each, and gives each a verdict before anyone adds them up. The evidence comes from the environment itself: the solutions and their layers, the Dataverse tables and relationships, the plug-in and flow inventories with their run history, the data in the tables the business depends on, and interviews about how the work is really done.

That inspection is what our Dynamics 365 health check and technical audit delivers as a fixed-scope assessment, including the second-opinion method and a prioritized remediation plan, so it is not repeated here. What this page adds is how to read those findings as a salvage or rebuild decision. Where the environment is completely undocumented, the reverse engineering steps are in our guide to taking over an undocumented Dynamics 365 environment.

How do you tell reusable configuration from bespoke work that will have to be redone?

Sort every component into standard configuration, supported customization and bespoke code, then ask of the last group whether it is load bearing and whether anyone can explain it. Standard configuration, meaning tables, columns, forms, views, business rules, business process flows, security roles and dashboards, is cheap to keep because it is visible, documented by the platform itself and supported through Microsoft release waves. Even when it is untidy, tidying it is a smaller job than rebuilding it.

• Read the solution layers. Components in managed solutions from a clean release path are easy to keep; a heavy unmanaged layer in production, or changes made directly in the default solution, means nobody can be sure what the real build is.
• Check how much of the behaviour reimplements something the platform already does, such as custom assignment, custom duplicate detection or custom approval tables. Each one is a candidate to replace with configuration rather than a reason to rebuild everything.
• List the bespoke components that the business would stop without. A short list of well understood custom pieces is normal; a long list nobody can explain is the finding that matters.
• Note what is simply unfinished, such as a form with half its sections or a flow that never went live. Unfinished work is scope still to deliver, not evidence that the finished parts are wrong.

How sound does the data model need to be to keep the build?

Sound enough that the processes and reports the business needs can be expressed without fighting it. The data model is the most expensive thing to change later, because every form, view, flow, plug-in, integration and report depends on it, so it deserves more weight in the decision than any screen.

Walk the main processes through the model on paper: a lead becoming an opportunity and an order, a case moving through its stages, a work order being scheduled and closed. Where each step lands on a table and a relationship that makes sense, the model is sound even if much is missing. Where the walk needs workarounds, such as one generic table holding several unrelated things, status stored in free text, a many-to-many relationship where the business has one owner, or duplicated tables for the same concept, the model is working against you.

A flawed model does not automatically mean a rebuild. Many problems can be corrected incrementally, and our guide to Dataverse data model remediation covers how. It points to rebuild when the flaw sits in the core tables every process touches and there is little working build on top of it worth protecting.

How do you decide whether the migrated data can be trusted?

Reconcile it rather than sampling it by eye. Compare record counts per table against the source for the whole table and for the business subset that matters, check owners, statuses and currency on the records that carry money or obligations, look for records that lost their parent or lookup during the load, and measure duplicates with rules rather than impressions.

The decision turns less on how bad the data is than on whether it can be fixed or reloaded. Duplicates and gaps are routine to clean, and our guide to Dynamics 365 duplicate data cleanup covers the method. If the source system is still available and the mapping can be recovered, a bad load can be run again into a sound model. The serious case is data that cannot be reconciled and cannot be reloaded because the source has been switched off, and in that case the data problem exists whichever route you choose. Plan for it separately rather than letting it decide the platform question.

How much of the custom code has to be readable and testable before you keep it?

All of the code you intend to keep changing. Custom code is only an asset if someone other than its author can read it, build it, test it and deploy it through a controlled path. Check each piece against four questions.

• Is the source in a repository your organization owns, and does it match what is registered in production? Assemblies without source can be decompiled, but decompiled code is a reference for rewriting, not a codebase to maintain.
• Can it be built and deployed to a test environment by someone new, from the repository and written steps alone?
• Can its behaviour be tested outside production? Plug-in logic can be unit tested, as our plug-in unit testing guide describes; code that only works against live data is a risk you carry.
• Does the contract give you the rights to it? If the previous party claims the intellectual property in a component the business depends on, take the contract terms to your legal advisers and plan as if that component will need replacing.

What does the business actually need compared with what was built?

Write the current need down before judging the build against it, because the original scope is often the wrong yardstick. Implementations that ran long frequently outlived the process, the organization or the product they were designed for, and scope was added along the way that nobody uses.

List the handful of outcomes the system must deliver in its first usable release, in business language: who records what, what gets routed where, what management needs to see. Then map each outcome to what exists. Three results are possible for each line: already built and usable, partly built and finishable, or not built or built for a different process. The balance of those three is the most honest single measure of how much of the investment is still worth something.

Remove built scope the business does not need from the calculation entirely. It is neither a reason to keep the build nor work that has to be finished.

Which signals mean rebuilding is the right answer?

Rebuild is right when the foundation is wrong, not when the finish is missing. These findings justify it, each written into the recommendation with its evidence. Often only one component, process or integration meets them, and the rebuild should be limited to that.

• Core business logic lives in custom code with no source, no tests and nobody who can explain it, and changing it safely would cost as much as writing it again from documented behaviour.
• The data model fights the main processes in the core tables, and there is little working build on top of it worth protecting.
• Production is so layered with unmanaged changes that no release can be trusted and nobody can reproduce the environment from anything outside it.
• The business need has moved so far that most of what was built serves a process that no longer exists.
• The platform itself does not fit: the licensing model never matched how the system would really be used, or the organization cannot adopt the Microsoft ecosystem.

Which signals mean the remaining work is smaller than it feels?

Salvage is usually right when the problems are visible, specific and on the surface. These signals mean finishing is likely to cost less than users expect.

• Most of the build is standard configuration, and the complaints are about missing forms, views, dashboards or steps rather than wrong behaviour.
• The main processes walk cleanly through the data model, even if some tables and relationships are still to be added.
• The data reconciles to its source, or the source is still available and the load can be repeated.
• Custom code is limited, in a repository you own, and deploys through a path someone else can follow.
• The failures cluster around a few causes, such as one integration, one badly ordered set of automations or the security model, that can be fixed without touching the rest.
• Users went back to spreadsheets because the release was incomplete or untrained, not because the design contradicts how they work.

How do you cost salvage and rebuild on the same basis?

Price both routes against the same target: the first usable release the business defined, not the original scope. A rebuild estimate that leaves out migration, parallel running and retraining will always look cheaper than finishing, and a salvage estimate that leaves out the debt it inherits will always look cheaper than a rebuild. Put every line below into both columns, even when the answer for one route is nothing.

When is rebuilding on Dataverse or a custom stack honestly the right call?

A rebuild on Dataverse keeps the platform and replaces the build. It is right when Dynamics 365 or Power Platform still fits the business and its licensing, but the foundation of this particular implementation, usually the data model, the code or the release path, cannot be trusted. Reusable parts, such as security roles, reference data or a sound integration, can often move across into the clean build.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. A rebuild on a custom stack changes the platform. It is right when the implementation failed partly because the platform never fitted: most users needed light access and the per-user licensing did not scale, the organization does not run on Microsoft 365, hosting or data rules exclude the public cloud, or the core process needed so much custom code that configuration added little. In those cases a custom-built CRM on React, Node.js, PostgreSQL or .NET is a legitimate outcome, and whether to leave the current platform at all is covered in our guide on whether to stay, fix or migrate a CRM.

Neither rebuild fixes the causes that sat outside the technology, such as unanswered decisions, uncontrolled scope or no named owner. Name those causes in the recommendation, or the second attempt repeats them.

What does a mixed salvage and rebuild decision look like in practice?

It is the most common honest answer. The assessment marks every finding keep, rework, rebuild or delete, and the decision is the pattern those marks make rather than a single verdict for the whole system. A typical shape keeps the standard sales or service configuration and the security model, reworks the automations that fight each other, rebuilds one integration or one custom component that has no source, deletes the scope nobody uses, and reloads a subset of data into a corrected table.

Sequence it so the business gets a usable release early: stabilize, deliver the kept and reworked parts, then replace the rebuilt components one at a time behind the working system. The way a takeover moves from stabilization to that plan is set out on our Dynamics 365 project rescue and takeover page.

How does Solzet help you decide whether to salvage or rebuild?

We read the environment before we give an opinion, and we do not price a rebuild until the assessment shows one is needed. The assessment covers the five dimensions on this page, records the evidence for each, marks every finding keep, rework, rebuild or delete, and costs the routes on the same basis. The written result is yours whatever you decide, and it is written so your own team or another partner can act on it. Sometimes the honest answer is rebuild, and we say so.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work across Sales, Customer Service, Field Service and Customer Insights, directly for your team or white-label for Microsoft partners. We do not assess or rebuild Dynamics 365 Finance, Business Central, NAV, Finance and Operations or other ERP implementations. Start with the health check and technical audit for the assessment on its own, or the project rescue and takeover service if the system also needs stabilizing now.