Encompass SDK to API Equivalents: What Replaces What
The most common question in any SDK migration planning call is the simplest one: “we have X built on the SDK — what does X become?” ICE’s sanctioned replacement stack has four destinations, and every SDK component you inventory will land in one of them (or in the recycle bin, which is the best outcome of all).
Here’s the map we use.
The four destinations
| You have (SDK-era) | It becomes |
|---|---|
| Desktop Smart Client plugins | Developer Connect APIs for the logic, Plugins 2.0 for in-app extensibility, or native functionality where it fits |
| Custom desktop input forms | Encompass Web input forms — rebuilt, not ported |
| Standalone SDK apps (batch jobs, services) reading/writing loans | Developer Connect REST APIs — server-side services calling the v3 loan endpoints |
| Polling loops watching for loan/field changes | Webhook events — event-driven notifications pushed to you, including field-level change events |
| Field-trigger logic inside plugins | Native business rules and the Encompass Workflow Engine where the logic is declarative; API-driven services where it isn’t |
| Legacy service ordering (appraisal, title, flood, verifications) | Encompass Partner Connect (EPC) |
| SDK authentication (Encompass credentials, in-process session) | OAuth 2.0 — token-based API auth with instance-scoped credentials |
The architectural shift underneath the table
Mapping components one-to-one misses the bigger change: the SDK ran inside the session, synchronously, with full trust. The API stack runs outside, over REST, asynchronously, with scoped credentials. Three consequences worth planning around:
1. Push replaces pull. SDK-era automations poll: query the pipeline every few minutes, diff the results, act. The API-era pattern inverts this — you subscribe to webhook events and ICE notifies you when something changes. Ported polling loops technically work on the REST APIs, but they’re the slowest, most rate-limit-hungry way to use the platform. Refactoring to events is part of the migration, not an optional polish step.
2. Logic moves out of the client. A Smart Client plugin lived on every user’s desktop. Its replacement usually lives in one place — a small service you host (or we host) that reacts to events and calls the APIs. That’s operationally better in every way: one deployment, one log, one thing to monitor. But it means “migrate the plugin” is really “stand up a service,” and your inventory should scope it that way.
3. Some things shouldn’t be rebuilt at all. Native business rules and the workflow engine cover a real share of what lenders once wrote plugins for — field validation, conditional requirements, milestone automation. Config beats code: no hosting, no maintenance, survives every Encompass release. Run each component through a rewrite-vs-native decision before anyone writes a line.
The components without a clean equivalent
Be honest about the hard 20%: UI-heavy Smart Client plugins that drew custom panels inside desktop Encompass don’t have a mechanical translation. The question for each is what job the UI was doing — and whether that job is better served by a web input form, a Plugins 2.0 extension, or a small external tool the APIs feed. This is rethink territory, and it’s where migration estimates go wrong when they’re built by counting plugins instead of understanding them.
How to use this map
Take your SDK usage inventory, add a “destination” column, and assign every row to one of the four targets — or to retirement. The rows that map cleanly to APIs and EPC are schedule-fillers: predictable, estimable, safe to run in parallel with the SDK version until outputs match. The rows that don’t map cleanly are your real project. Identify them early, because they’re the ones that need design time before build time — and with the deadline fixed at December 31, 2026, design time is what runs out first.
We build these component maps every week — a free assessment gets you your instance’s version of this table, with a fixed-scope price per row.