On this page
We do not usually write about our own plumbing. Most of what we publish is about your records: what belongs in a minute book, why a cap table is not a corporate record, where warrants go to hide. This post is different, because the change behind it is the largest technical decision we have made since launch, and because it touches the one thing a records platform cannot treat casually: the software responsible for holding the legal record of who owns your company.
On September 10, 2026, we moved the entire Octelligence production platform onto a rebuilt foundation. If you logged in that day, you saw nothing new. Your corporations, certificates, cap tables, minute books, and workflows were exactly where you left them. That was the goal. What changed was underneath.
This is the story of what we replaced, why we took on a rebuild of this size, how we moved a live records platform without turning it into a disruptive migration project for our customers, and what the new foundation means for where Octelligence goes next.
What we changed
Every application has an engine: the backend that stores the data, applies the rules, handles authentication, and answers every request the application makes. Octelligence launched on one built with PHP and CodeIgniter. It was a sound foundation for getting the product into the world, validating the workflows, serving customers, and expanding from corporate records into a broader platform for ownership, governance, and equity.
We have now replaced that backend, end to end, with a new one built on NestJS and TypeScript. Internally, we call it API v2.
Three important things changed with it. Ledger and Equity Vault now operate through one API, so the records maintained by your team and the information made available to stakeholders come from the same underlying platform. The data model was redesigned rather than simply copied over, giving us the opportunity to remove accumulated workarounds and make the relationships between records clearer. And the application is now strongly typed, allowing us to catch entire categories of mistakes during development, before code reaches production.
The original API served Octelligence well. API v2 is the foundation we intend to build on for what comes next.
Why a records platform rebuilds its foundation
Rewriting a working backend is not a decision anyone makes lightly, and it is fair to ask why we did it.
The answer is that the stakes of what we store are unusually high. Octelligence holds the registers that establish who owns a company, the resolutions that record who authorised what, the certificates that evidence ownership, and the records that may later be scrutinised by lawyers, accountants, investors, lenders, or a buyer's counsel during diligence. The software underneath those records has to be worthy of them for a long time, not simply adequate for the next release.
Our first backend served us well, but as the platform expanded, the constraints were beginning to show. Features that touched several parts of the system took more care to implement safely. The data model had accumulated workarounds that made certain changes more complicated than they needed to be. And as Ledger, Equity Vault, corporate governance, securities, compliance, and portfolio management became more interconnected, we wanted the architecture underneath them to reflect the platform Octelligence had become.
For a system of record, that matters. The risk associated with changing the platform should fall over time as the architecture becomes more mature, not increase because each new feature is being layered onto old compromises.
Rebuilding on a cleaner, strongly typed foundation resets that curve. It gives us an architecture designed for the product we are building now, rather than one continually adapted from the product we started with.
How we did it without a big bang
The riskiest way to replace a backend is to switch everything over on one dramatic night and hope. We took the opposite approach.
The new platform was built beside the old one, not on top of it, and deployed on separate infrastructure so the running production system could remain undisturbed while API v2 was being developed. We worked through the rebuild in a sequence of gated phases, reimplementing the platform piece by piece, from identity and access through the corporate registry, securities, governance, minute book, compliance, and the services used by Ledger and Equity Vault.
Each stage was checked against real production data and existing workflows rather than built from assumptions about how the platform behaved. Authentication was rebuilt so the new API issues and validates its own credentials, including two-factor verification during sign-in. Document rendering, including the machinery behind share certificates and other generated records, was rebuilt and verified before it was allowed to carry production traffic.
Once the application was complete, the data was migrated and reconciled against the existing platform. The production cutover itself followed a written, step-by-step migration plan, with checkpoints throughout the process and the ability to reverse course if something did not reconcile as expected.
The result on the customer side was intentionally uneventful: no downtime, no export, no re-import, no changed URLs, and nothing to reconfigure.
The best outcome for a foundation rebuild is that the people who depend on the platform never have to think about the migration at all. That is the outcome we aimed for.
What it means for the firms who trust us
A rebuild is only worth writing about if it changes something you care about. This one does.
- One source of truth, by design. Ledger and Equity Vault now operate through the same API and underlying data model. The previous architecture maintained parts of the equity experience separately. That separation is gone. Your team and your stakeholders now interact with the same underlying record, subject to their respective permissions and access.
- Stronger guardrails around your data. Strong typing allows us to catch entire categories of mistakes during development before code reaches production. Combined with application validation, clearer domain rules, and a redesigned data model, it gives us better safeguards around the records the platform is responsible for maintaining.
- Security rebuilt as part of the platform. Authentication, credentials, and two-factor verification were rebuilt as part of API v2 rather than simply carried forward unchanged. That gives us a cleaner security foundation to build on as the platform continues to grow.
- Improvements can arrive faster. A cleaner architecture is easier and safer to extend. We did not have to wait long to prove it: the day after the production cutover, in-app support went live inside Ledger, the first feature shipped natively on the new API. More will follow.
- A foundation designed for longevity. Companies may keep their corporate records for decades. Firms managing portfolios may maintain hundreds of entities over many years. The technology underneath those records needs to scale without requiring the compromises we started with. API v2 was designed with that horizon in mind.
What stays exactly the same
Nearly everything you interact with.
Your corporations, share registers, certificates, cap tables, resolutions, people, securities, and documents remain where they were. Your login works as it did. The URLs you have bookmarked still resolve. Your minute book is still your minute book.
The work of the rebuild was to change the engine without changing the drive. If the only way you learn that any of this happened is by reading this post, then the migration worked exactly as intended.
What comes next
With the platform now running on its new foundation, the work moves back toward the parts of Octelligence you can see.
We will continue shipping improvements across Ledger and Equity Vault, keep the changelog current, and build new capabilities on top of an architecture designed to support them without continually working around decisions made years earlier.
If you want the technical account of the rebuild, including the sequence of phases and what shipped during the migration, you can read the API v2 release notes. Ongoing product changes are published in the changelog, and our commitments around security and service availability are available on the security and status pages.
The bottom line
The best infrastructure work is invisible to the people it serves.
You did not have to migrate anything, learn anything new, or lose access to anything. Yet the platform holding your corporate records is now running on a foundation designed to be more consistent, easier to maintain, safer to extend, and faster for us to improve than the one it replaced.
Same Octelligence, new engine.
We rebuilt the foundation precisely because of what you keep on top of it. And if we have done our job properly, you should not have to think about that foundation very often again.
