How to Modernise a Live Trust Product Without Breaking It

Modernising software that nobody is using yet is, relatively speaking, easy. You can move fast, break things, iterate without consequence. Modernising software that people already rely on every day for something that matters — SecureShare is used as a virtual data room, holding confidential material shared between investors, partners and advisers — is a completely different discipline, and I want to be specific about why, because "we modernised it carefully" undersells what that actually requires.

Why a trust product raises the stakes on every decision

A data room's entire value proposition is that access is controlled and predictable. That's not one feature among several; it's the product. Which means every change made during modernisation — a rebrand, an interface transition, a cutover to a canonical domain — has to be evaluated first against a question most product updates don't have to ask: does this change put that predictability at risk, even temporarily, even in a way that's fixed within minutes?

A consumer app can tolerate a rough migration window. A user might grumble about a confusing new layout for a day and move on. A trust product doesn't get that grace period in the same way, because the thing users are trusting it with — confidential material, sometimes tied to active negotiations or investor relationships — doesn't pause just because the underlying product is mid-migration. That reframes every technical decision as a business-continuity decision first and a technical decision second.

What actually had to be planned, not just executed

The domain cutover is the clearest example of why sequencing matters more than execution speed here. Moving to a canonical domain sounds like a DNS change. In practice, for a system where existing users have bookmarked links, saved credentials against a specific domain, and in some cases embedded links to shared documents in their own external communications, a domain cutover has to be planned as a multi-stage transition — old domain still functional during a defined window, clear signals to users about the change, and a cutover sequence that doesn't strand anyone mid-session with an active document open.

The interface transition carried a related but distinct risk: regular users, some of whom interact with the product only occasionally — an investor logging in once a quarter to check a data room, say — needed to be able to find what they needed even if the interface had visibly changed since their last visit. Designing for an infrequent user's continuity is a different problem than designing for a daily power user's efficiency, and a rebrand that optimises purely for the second risks quietly failing the first.

Rollback readiness as a design requirement, not an afterthought

The decision I'd defend most strongly from this whole modernisation is treating rollback readiness as a requirement from the start, not a contingency plan sketched out after something went wrong. For a live trust product, "we can fix it if something breaks" isn't good enough on its own — the question has to be "how fast can we fix it, and what's the actual damage in the window before we do." Planning the rollback path with the same care as the forward migration path meant that if a specific stage of the cutover had surfaced a real problem, the response wouldn't have been improvised under pressure. It would have been executing a plan that already existed.

This is, I think, the single biggest practical difference between modernising a live trust product and modernising almost anything else: the cost of an unplanned rollback, discovered and improvised in the moment, is measured not just in engineering time but in whether users' confidence in the product's basic promise survives the incident. That's a harder thing to repair than a bug.

What actually went into the decision-making

Every stage of this modernisation got evaluated against the same standing question: if this specific step goes wrong, what's the blast radius, and can it be contained and reversed before it affects anyone's actual access to their documents? That question shaped the sequencing more than almost anything else — some technically simpler changes got deferred because their failure mode was harder to contain quickly, while some more complex changes got prioritised earlier because their rollback path was cleaner.

The sequencing decision I'd make again

If I had to isolate the single sequencing decision that mattered most, it was refusing to bundle the rebrand and the domain cutover into one simultaneous change, even though doing both at once would have been faster and, on paper, less disruptive than two separate transition periods. The reasoning was that if something went wrong during a combined change, diagnosing whether the problem originated in the rebrand or the domain migration would itself become a time-consuming investigation, at exactly the moment speed of diagnosis mattered most. Separating them meant that if an issue surfaced, its source was already narrowed by which stage was active when it appeared. That's a small amount of extra calendar time traded for a meaningfully faster response time if something did go wrong — a trade I'd make again for any live trust product, even though it's an invisible decision that nobody using the product would ever notice either way.

The honest limitation

I don't want to claim this modernisation was executed with zero friction for users — a rebrand and interface transition of this scope, even planned carefully, produces some genuine disruption; someone's saved bookmark stops working for a moment, someone has a "wait, is this still the real site" hesitation the first time they see the new interface. What I can defend is that the failure modes that would have genuinely mattered — a broken link stranding someone with unfinished access, a cutover window that left the system in an inconsistent access state — were the ones actively designed against and planned for rollback. The smaller frictions were accepted as a real but bounded cost. I don't think there's a version of modernising a live trust product that has zero cost to existing users; the discipline is in being deliberate about which costs are acceptable and which ones aren't, rather than discovering the difference after the fact.