Case study · Salesforce ISV

From legacy org to Salesforce ISV product

Two attempts had already failed. The third shipped: an OEM-licensed managed package, built in tandem with a live production platform, and taken through the AppExchange security review.

Role
Salesforce Architect & ISV Engineer
Sector
Driver-training & examination SaaS
Scope
Architecture · Packaging · Integrations · DevOps
Outcome
OEM-licensed 2GP package in production, on a stable, traceable platform

A product trapped in a single org

A Dutch software company runs its entire product on Salesforce: scheduling, resource planning, exam registrations with the national exam authority, invoicing, and payments. The full daily operation of driving schools. The platform had been built at high pace inside a single unmanaged org. It ran, but it was unstable and unpredictable, and it couldn't be sold: no packaging, no namespace, no way to install it on a customer's org.

The goal was easy to state and hard to do: turn that org into a real Salesforce ISV product. A managed package, distributed under an OEM license, installable and upgradeable on every customer org.

Why two attempts had already failed

An unmanaged org accumulates freedoms a managed package doesn't forgive. Two engineers had tried the conversion before. Both attempts stalled on the same walls:

  • The codebase, roughly 150,000 lines of Apex and over 400 flows, wasn't namespace-aware. A managed package forces a namespace onto nearly every reference in code and metadata. Converting that by hand is where the earlier attempts drowned.
  • The data model leaned on platform features an OEM license doesn't allow.
  • The org held everything at once: the product itself and customer-specific work, with no clear boundary between what belonged in the package and what didn't.
  • Source control and production had drifted apart. Git and the org were chronically out of sync, and production would fail at times.
  • Errors vanished without a trace: little structured error handling in Apex or Flows, no monitoring. Failures surfaced as customer complaints.
  • And the platform couldn't stop. Every step had to land in tandem with a live production org, while a team kept shipping features on it.

The approach

Make it observable, then make it robust

First order of business: failures had to stop vanishing. I introduced structured logging, monitoring, and dashboards, added defensive error handling throughout Apex and Flows, and worked the standing error backlog down to zero. From then on, every failure was caught, logged, and traceable. A platform you can trust enough to operate on.

An architecture built to be packaged

I introduced enterprise-grade Apex patterns and split the platform into two packages: a data layer and an application layer. That separation became the backbone of the transformation. It carried the product through the AppExchange security review and made OEM licensing possible. The OEM-restricted features were re-architected out of the data model along the way.

Alongside it ran a deep refactoring of the codebase itself: clearer, more intentional code, and a layer of shared platform utilities the whole product now builds on.

Namespace conversion at scale, automated

Converting 800+ Apex classes and thousands of metadata files by hand was exactly where the earlier attempts had died. So I built tooling that rewrites the entire codebase and metadata tree to be namespace-aware automatically, and repeatably, so the package could be rebuilt from the evolving source at any time. That single step turned unfeasible into scheduled.

Pipelines for everything

One command builds a complete environment: a scratch org with both packages installed, including automatically built beta versions, or an unmanaged scratch org for development work, with realistic data seeded automatically. Test runs were hardened against platform flakiness, and releases verified end-to-end before they ship. Salesforce DevOps as a habit, not a project.

In tandem with production

No freeze, no big-bang migration. The transformation ran alongside the live org and the team's parallel feature work. Quality, security, and architecture improved piece by piece: each change shipped to production first and flowed back into the package, while the same automation kept source, package, and production aligned. Daily operations never stopped.

Shipped with Salesforce, not just on it

I worked directly with Salesforce's ISV team and partner manager and took the product through the security review. I also set up the full ISV operation around it: the Partner Business Org with Environment Hub and the License Management App (LMA) for license management, and a Trialforce Source Org (TSO), the template org from which new customer orgs are provisioned automatically under the OEM model.

Along the way, the platform's seven external integrations (accounting, payments, the national exam authority, chamber-of-commerce data) were rebuilt or hardened, plus a SAML SSO identity provider.

The result

An installable, production-ready managed package, distributed under an OEM license and running on customer orgs. The first package passed the AppExchange security review, with the second in final review. Where two earlier attempts had stalled, the third shipped, without interrupting production along the way.

The platform itself came out better than it went in: stable and predictable, with better performance, every error caught and logged, reproducible builds, seeded environments on demand, and automated customer provisioning through the TSO. A Salesforce architecture a team can build on for years.

What stalled twice now ships. An internal org became a product you can sell.

The platform in numbers

800+
Apex classes
±150k
Lines of Apex
400+
Flows
90+
Lightning components
7 + SSO
Integrations
1,700+
Commits in ten months

Sitting on a Salesforce org that should be a product?

Packaging, namespaces, security review, OEM licensing: I've taken a platform through every step, alongside a live production org.

Get in touch