Source-code handover: when a business should own the codebase.

Between SaaS and on-premise lies a deeper level of ownership: receiving the platform’s entire source code. This is the strongest option for sovereignty — you keep not just the data but the system’s “recipe” — but it comes with commensurate responsibility and isn’t for every organization. This article clarifies what a source-code handover actually is, when it makes sense, and a capability checklist to know whether you’re ready.

What a source-code handover really is — and isn’t

You receive and own the platform codebase, run it on your own infrastructure, and have the right to read, modify, and extend it along your own roadmap. This isn’t a “locked copy” or an escrow license that only opens if the vendor goes bankrupt. Nor is it public open source — it’s a contractual handover for your organization specifically, with clearly defined rights and obligations. The crux: from the moment you receive it, you hold the keys to both the features and the direction of development.

When this model actually makes sense

A source-code handover isn’t the premium default for every large enterprise. It makes sense when at least one of the following is true:

• The highest level of sovereignty or compliance requirement: industry regulation or customer contracts require you to prove full control of the code that runs.
• Customization needs that go far beyond configuration: you need to change core logic, not just toggle features or adjust parameters.
• The operating system is a core capability: you treat this software as a strategic asset to control in-house for years, not an outsourced utility.
• A long-term view on vendor risk: you want to eliminate single-vendor dependency and are willing to invest internally in exchange.

If none of the above is true, on-premise is usually enough: you still keep the data inside your perimeter without bearing the cost of maintaining a codebase.

The real cost: ownership isn’t abandonment

The biggest trap of a source-code handover isn’t at the moment you receive it, but in the years after. As you modify the codebase in your own direction, it starts to diverge from Apus’s original development line — and each update, security patch, or new feature from upstream becomes increasingly hard to merge. This is fork drift, and it’s the biggest hidden cost. Owning the source code means you also take on the responsibility for maintenance, bug fixes, and security that the vendor previously carried.

What capabilities to prepare

Before signing a handover, honestly compare against your internal capabilities:

• A technical team capable of reading, maintaining, and extending the platform — not just a few developers who can make small edits.
• A process for taking in updates from Apus’s development line, along with a branch-management strategy to limit fork drift.
• Change-management discipline: testing, a separate staging environment, and a controlled release process for a core operating system.
• A long-term operating budget, not just the initial cost — people, infrastructure, and time are the bulk of total cost.

How to decide correctly

A simple test: picture the next three years. If you see your team actively building its own features on the platform and treating that as a competitive advantage, a source-code handover pays dividends. If you just want peace of mind about the data and rarely need to change core logic, you’re paying for a level of autonomy you won’t fully use — on-premise is the right stopping point. And because all three models share one data layer, you’re not forced to decide early: many organizations start with SaaS or on-premise, then take a source-code handover once their internal capability has matured. The highest sovereignty is only worth it when you have the team to exercise it.

Related articles