Encompass Plugins 2.0: What We Know, and What It Changes About Your Migration
When ICE laid out what replaces the retiring SDK, it named four sanctioned paths: Encompass Developer Connect APIs, Encompass Partner Connect APIs, native functionality (business rules and the Encompass Workflow Engine), and Plugins 2.0. Three of those are well-trodden. The fourth is the one generating questions in every migration conversation, so here’s an honest accounting of what’s known — written July 2026, and we’ll update it as ICE publishes more.
What Plugins 2.0 is
Plugins 2.0 is ICE’s successor model for in-application extensibility — the replacement for the job Smart Client plugins did in desktop Encompass, rebuilt for the platform ICE is actually investing in. ICE has tied its arrival to the Encompass 26.2 release cycle. Where the legacy SDK loaded compiled .NET code into a desktop client, the successor model belongs to the Encompass Web era, and that context tells you most of what you need for planning purposes: it is a forward-looking extensibility surface, not a compatibility layer. Nobody’s legacy plugin DLL is going to “just work” in it.
Where it fits among the four replacement paths
The practical question for any SDK component is which destination it maps to. Our working rule:
| The plugin’s job was… | The right destination is… |
|---|---|
| Validating fields, enforcing conditions, milestone automation | Native business rules / Workflow Engine — configuration, not code |
| Moving data, reacting to loan events, talking to other systems | Developer Connect APIs + webhooks — a server-side service |
| Ordering vendor services | Partner Connect (EPC) |
| Putting custom UI and interaction in front of the user, inside Encompass | Plugins 2.0 — this is its lane |
Notice how narrow that last lane actually is. When we map SDK components to their API-era equivalents, the majority of legacy plugins turn out to be logic and data-movement wearing a plugin costume — they only lived in a plugin because, in the SDK era, that was the only place code could live. Those migrate to APIs and rules today, with mature tooling and no dependency on anything still shipping.
The strategic mistake: waiting
Here’s the pattern we’re starting to see, and the reason this article exists: a lender looks at the four paths, sees that one of them is still maturing, and concludes the prudent move is to wait for Plugins 2.0 to fully land before starting the migration.
That logic inverts reality. The deadline is December 31, 2026 for everything SDK-based, and it does not move because one replacement surface is newer than the others. If you wait:
- The 80% of your inventory that maps to APIs, EPC, and native rules — all fully available now — sits unmigrated behind a dependency it never had.
- Your genuinely UI-bound components, the ones that do want Plugins 2.0, get compressed into the final quarter alongside everyone else’s, competing for the same scarce engineering capacity.
- January 1, 2027 arrives, and transitional access fees start accruing on the whole pile.
The sequencing that works is the opposite: migrate the API-and-rules majority now, run it in parallel, cut over component by component — and let the small UI-bound remainder be the thing that lands on Plugins 2.0 as it matures. That way the newest platform surface carries your smallest, most isolated risk.
What to do with your plugin inventory this week
Go through your SDK audit and mark every plugin with one of the four destinations above, using the “what was its job” test. Expect the Plugins 2.0 column to be short. If it isn’t — if your operation genuinely runs on rich custom UI inside Encompass — that’s exactly the situation where you want a rewrite-vs-native decision pass from someone who has done this before, because some of that UI exists only to work around limits the modern platform no longer has.
We’ll keep this piece updated as ICE publishes more. If you want your inventory mapped to the four destinations with real estimates attached, the assessment is free.