Rewrite the Plugin, or Use Native Functionality? A Decision Checklist
The reflex reaction to the SDK sunset is to rebuild everything you have, one-for-one, on the new APIs. That’s also the most expensive possible reading of the situation — and the one a billing-by-the-hour vendor is least motivated to talk you out of.
A meaningful share of the plugins in a typical Encompass instance shouldn’t be rewritten at all. Some duplicate functionality that Encompass now does natively. Some automate workflows the business quietly abandoned two admin generations ago. Some should be consolidated with three sibling plugins into one clean service.
Here’s the checklist we run every plugin through before writing a line of migration code.
Question 1: Does anyone still use it?
Sounds obvious. Isn’t. Instances accumulate plugins the way garages accumulate boxes — and the person who commissioned the thing left in 2021.
Check: logging/telemetry if the plugin has any; otherwise ask the ops team to name who uses it and for what. If nobody can name a user within a week, it goes on the retire list (with a parallel-run safety period before anyone deletes anything).
Typical result: 15–30% of the inventory retires outright. That’s free money — every retired plugin is a rewrite you don’t pay for.
Question 2: Did Encompass catch up?
Many plugins were built to paper over gaps that no longer exist. Field-level automation, conditional task creation, enhanced conditions handling — capabilities have shipped in the years since your plugin was written, in both Encompass itself and the surrounding platform.
Check: for each plugin, write one sentence describing what it does in business terms (“prevents locking when X,” “auto-orders flood cert when Y”). Then check whether current native functionality — business rules, workflow engine, Encompass Web capabilities — covers it.
Typical result: another meaningful slice becomes configuration work instead of engineering work. Configuration is cheaper, and it survives future platform changes better than custom code.
Question 3: Is it one plugin, or five plugins wearing a trenchcoat?
SDK-era development encouraged point solutions: one plugin per annoyance. When you migrate to an API-first architecture, the economics invert — one well-designed Developer Connect service with webhook triggers can replace a family of plugins that each poked at the same loans.
Check: group your inventory by business domain (disclosures, conditions, assignments, vendor orders). Anything in the same group is a consolidation candidate.
Typical result: rewrite count drops again, and what you build is more maintainable than what it replaces.
Question 4: For what’s left — rewrite faithfully or redesign?
Now you’re down to the plugins that genuinely need to exist and have no native equivalent. One last fork:
- Faithful rewrite when the workflow is sound and the risk of change outweighs the benefit. Same behavior, new platform, minimal retraining.
- Redesign when the plugin encodes a workaround for a constraint that no longer exists — desktop-only assumptions, polling because webhooks weren’t available, manual steps that exist because the SDK couldn’t do something the API now can.
A useful tell: if explaining the plugin to a new hire requires the phrase “because back then, Encompass couldn’t…,” redesign it.
The output: a migration map, not a quote for everything
Run the full inventory through those four questions and you get four lists — retire, replace-with-native, consolidate, rewrite — each with a cost profile from zero to full engineering effort. That’s the document worth having before you talk to any migration vendor, including us: it converts “migrate everything by December 31, 2026” from an open-ended engagement into a fixed, priceable scope.
Want the four lists without doing the archaeology yourself? Our free SDK assessment produces exactly this map — and it’s yours to keep regardless of who does the build.