Cloud-native vs legacy ETRM

The choice between a cloud-native and a legacy ETRM is often framed as a question of hosting, whether the software runs on your servers or someone else’s. That framing misses the point entirely. The real difference is structural: a legacy platform stitches separate trading, risk, and back-office systems together and reconciles between them, while a cloud-native platform puts every function on one governed model, so the numbers reconcile by construction rather than by overnight batch. This one architectural fact cascades into cost, speed, resilience, and trust, and it is why a legacy platform merely lifted into the cloud does not become cloud-native. It carries its on-premises assumptions with it.

Understanding this distinction is what lets a buyer see past a demonstration, where both kinds of platform can look similar, to the daily reality of running each. Everything else in this handbook follows from it. The reconciliation team, the overnight batch, the months-long change request, the discomfort of numbers that came from different copies of the same trade, all trace back to whether the platform runs on one model or several.

It is worth being precise about what cloud-native means, because the word is abused. A cloud-native platform is one designed from the start to run as an elastic, multi-tenant, API-first service on one governed data model, with reproducible infrastructure and continuous delivery. A legacy platform is one designed as an on-premises application, assembled from modules with their own data stores, operated by hand and changed by development project. Hosting a legacy platform on cloud infrastructure changes where it runs, not what it is.

The practical consequence for a buyer is that the two architectures cannot be told apart by asking what a platform does. Both a cloud-native and a legacy platform capture trades, value them, and settle them; the list of things they do is nearly identical, which is exactly why a feature comparison is so uninformative. The architectures are told apart by asking how they do those things: whether a single record flows through the lifecycle or several copies are reconciled, whether a number computed in one place is trusted everywhere or checked against another copy first. These how questions are the ones this handbook trains you to ask.

There is also a cultural dimension worth naming early. Organisations that have run legacy platforms for years internalise their constraints as facts of life: of course risk is available in the morning, of course a new market takes months, of course a team reconciles the books. When such an organisation evaluates a cloud-native platform, it must first unlearn these assumptions, because the platform removes the constraints that produced them rather than merely easing them. Much of the value of the architectural difference is invisible to a buyer who is still measuring against the constraints of the system they are trying to leave.

When you sit through a platform demonstration, hold one question in mind throughout: for every capability shown, is this one record flowing through the lifecycle, or a copy that will later be reconciled? Ask the presenter to book a trade and then show it in risk and in settlement, and ask explicitly whether those three views are the same record or three copies. The answer, given plainly, tells you more about the platform’s architecture and its decade of consequences than any slide about features can.

To understand why legacy platforms are shaped as they are, it helps to know how they came to be. The first generation of trading systems automated individual functions: a front-office trade blotter here, a risk engine there, a back-office settlement system somewhere else, each built or bought separately to solve a specific problem. Integration between them came later, bolted on as the need to share data became painful, and it took the form of overnight files and reconciliation rather than a shared model, because that was what the technology of the time allowed.

Vendors then consolidated these functions into suites, often by acquiring the separate systems and packaging them together. The packaging hid the seams from the buyer but did not remove them: underneath, the suite was still several systems with their own data stores, now sold as one product. This is the architecture most legacy platforms still carry, and it is why they reconcile internally. The seams are inherited from a history of assembly, not chosen.

Cloud-native platforms come from a different lineage. They were designed after the technologies that make a single governed model practical at scale, elastic compute, distributed data stores, event streaming, and continuous delivery, had matured. Being born after those technologies, they could be built around one model from the start rather than assembled from parts. The generational difference in when a platform was designed is much of what separates cloud-native from legacy.

The acquisition-and-package pattern also explains a subtler legacy trait: inconsistent data models between modules. When a suite is assembled from separately-built systems, each brought its own way of representing a trade, a counterparty, an instrument. Packaging them together rarely unifies those representations; it maps between them, which is another form of reconciliation, now hidden inside the product. This is why a legacy suite can struggle to answer a question that spans modules, such as total exposure to a counterparty across every commodity, without a report that stitches several models together.

Understanding this lineage protects a buyer from a common sales narrative: that a platform with decades of history is proven and therefore safe. Longevity does prove that the platform works, but it also usually means the architecture was designed for a world before elastic compute, event streaming, and continuous delivery, and that it has accreted modules and integrations ever since. Proven and modern are different properties, and a buyer should value both without confusing one for the other. The right question is not how long has this existed but when was its architecture designed, and has it been rebuilt since.

A revealing question to ask a vendor is when the platform’s core data architecture was last rebuilt, as opposed to extended. A platform whose architecture dates from an earlier era and has only been added to since will carry the reconciling, module-assembled shape of its origins, however modern its interface looks. A platform rebuilt around a single governed model in the modern era will not. The history of the architecture, honestly told, predicts the properties you will live with.

The defining property of a cloud-native ETRM is that trade capture, valuation, risk, scheduling, settlement, and reporting all operate on a single governed data model. A trade booked in the front office is the same record that risk aggregates and that settlement invoices. There is nothing to reconcile because there is only one version of each fact. A legacy platform, by contrast, is typically an assembly of modules, often acquired or built at different times, each holding its own copy of the trade. Those copies drift, and a reconciliation layer exists solely to force them back into agreement, a layer that costs money and effort every single day and that can never be fully trusted.

This is the root of most of the operational pain that trading operations attribute vaguely to their systems. The nightly batch that must complete before anyone trusts the morning’s numbers, the team whose whole job is chasing breaks between the front and back office, the discomfort of knowing that the risk number and the settled number came from different copies of the same trade, all of these trace back to the multiplicity of models. Remove the multiplicity, and the reconciliation, the batch, and the breaks disappear with it.

The single model is not merely a technical nicety; it is what makes trust possible. When there is one authoritative version of each fact, a number is either right or wrong, and it can be traced to its inputs. When there are several copies, a number is right in one system and wrong in another, and the organisation spends its energy deciding which copy to believe. That erosion of trust is the hidden tax of the many-model architecture, and it is paid in judgement and confidence, not only in reconciliation effort.

It is worth being concrete about what one model means in practice, because vendors use the phrase loosely. A genuinely single model means that when the front office amends a trade, the middle-office risk and the back-office settlement see the amendment immediately, because they are reading the same record, not a copy that will be updated later. It means there is no import, no synchronisation job, no as-of timestamp that differs between modules. A useful test during evaluation is to amend a trade in one screen and watch whether every other screen reflects it at once, or whether the change has to propagate.

The many-model architecture also imposes a hidden constraint on the pace of the business: the whole operation can only move as fast as its slowest reconciliation. If risk depends on a copy that is refreshed hourly, risk is at best an hour old, however fast the front office moves. If settlement depends on an overnight copy, settlement is always a day behind. The single model removes these internal speed limits, because there is no copy to wait for; every function is as current as the trade itself. That is a structural gain in tempo that no amount of tuning can give a many-model platform.

The concrete test for a single model is simple and worth insisting on during evaluation: amend a trade in one screen and watch every other screen. If the position, the risk, and the settlement view all reflect the amendment immediately, you are looking at one model. If any of them lags, requires a refresh, or shows an as-of time behind the others, you are looking at copies, and everything this handbook says about reconciliation, timeliness, and trust will apply.

Reconciliation is so normal in a legacy operation that its cost becomes invisible, absorbed into the way things have always been done. Measured honestly, it is large. There is the direct cost of the people who reconcile, often a dedicated team whose entire role exists only because the front and back office hold different copies of the trade. There is the cost of the delay: numbers cannot be trusted until the reconciliation completes, which pushes decisions to the next morning. And there is the cost of the errors that slip through, because reconciliation catches most breaks but never all of them.

Beyond these direct costs is a subtler one: the cost of building the business around the assumption that reconciliation is necessary. Processes are designed to wait for it, controls are designed to compensate for it, and people learn not to trust a number until it has been reconciled. This shapes the whole rhythm of the operation, and it is invisible precisely because it is everywhere. A cloud-native platform that reconciles by construction does not merely save the reconciliation team; it removes the assumption that shaped the operation, which is a larger change than it first appears.

A useful exercise during a current-state assessment is to trace one number, say the previous day’s profit and loss, from the moment a trade is booked to the moment the number is trusted, and count every reconciliation, every batch, and every manual check along the way. Most organisations are surprised by how long the chain is and how many people touch it. Each link exists to compensate for the fact that the number lives in several copies, and each link is effort that a single-model architecture simply does not require. The length of that chain is a good proxy for the reconciliation tax the architecture imposes.

There is also an opportunity cost hidden in reconciliation that rarely appears in any budget: the attention of capable people. The staff who reconcile are often experienced and numerate, exactly the people who could be improving the business rather than checking that two copies of a trade agree. Freeing them from reconciliation does not only save their salaries against the task; it redirects their capability to work that creates value. When the reconciliation tax is counted, this redirection of talent is often the largest and most overlooked part of the saving.

Before you evaluate any new platform, measure what reconciliation costs you today, because that number is both a large part of the case for change and a baseline you can hold a new platform against. Count the people, the delay, and the errors, and trace one key number from trade to trusted figure to see the chain in full. A platform that reconciles by construction should remove most of that chain, and quantifying the chain first is what lets you value its removal honestly.

A single governed model does not only remove reconciliation; it changes when the business can see its numbers. When a booked trade updates one shared model, valuation, position, and risk can update within seconds, so a desk manages its exposures as they develop. When each function holds a copy that is synchronised in a nightly batch, the desk manages yesterday’s risk against today’s market. The difference between intraday and overnight is not a tuning parameter; it is a consequence of the architecture, and it determines whether risk management is proactive or retrospective.

The cloud-native architecture supports a two-speed rhythm: frequent, lightweight valuation and risk snapshots for the intraday view, and scheduled heavier runs for portfolio measures like value-at-risk and counterparty exposure. Both run on the same governed positions, so the intraday view and the batch view never disagree about what the book actually contains. A legacy platform, locked into a batch paradigm and sized for its peak, cannot offer the intraday view without a reconciliation risk, because the intraday copy and the batch copy are different data.

The contrast becomes vivid during a volatile day. When a market moves sharply, a desk on a real-time platform sees its exposures change as the move happens and can act within the same session, hedging or unwinding while the information is still current. A desk on an overnight platform learns the full extent of the move the next morning, after the batch has run, by which time the market has moved again and the opportunity to respond in context has passed. Volatility is precisely when timeliness matters most, and it is precisely when the overnight architecture fails the desk hardest.

It is important not to mistake a fast screen for a real-time architecture. Some legacy platforms offer a front-office blotter that updates quickly, which can look like real-time risk. But if that blotter’s numbers are front-office estimates that will later be reconciled against the authoritative middle-office figures produced in batch, the speed is cosmetic: the fast number and the trusted number are different data, and the desk must eventually wait for the trusted one. Real-time in the sense that matters means the fast number and the trusted number are the same number, which only the single-model architecture delivers.

Ask each platform to demonstrate risk on a live book and then book a trade into that book, and time how long the risk takes to reflect it. Seconds means real-time on a shared model; minutes or the next batch means a copy. Then ask the harder question: is the fast number the trusted number, or will it be reconciled against a separate authoritative figure later? The gap between the fast number and the trusted number, if there is one, is the gap between the architecture you want and the one you are being shown.

It is tempting to treat intraday risk as a feature that any platform could add, given enough engineering. It is not. Intraday risk requires that the risk view reflect the positions that exist right now, which requires that booking a trade update the same data the risk view reads, within seconds. On a single governed model with an event-driven core, that is how the system already works; intraday risk is a natural consequence. On a many-model platform, the risk view reads a copy that is synchronised in batch, so making it intraday means either synchronising continuously, which reintroduces the reconciliation problem in real time, or accepting that the intraday view may disagree with the batch.

This is why a legacy platform can demonstrate an intraday risk screen and still not deliver trustworthy intraday risk. The screen may show numbers that update, but if those numbers come from a copy that has not yet been reconciled with the authoritative positions, they are indicative rather than authoritative. The buyer who wants real intraday risk must ask not whether the platform shows updating numbers but whether those numbers come from the same governed positions the batch uses. That is an architectural question, and it separates real intraday risk from a screen that merely refreshes.

Consider what it takes to retrofit intraday risk onto a many-model platform, because vendors are often asked to do exactly this. The engineering team must build a path that keeps the risk copy continuously synchronised with the authoritative positions, which means detecting every change, propagating it, and resolving conflicts, in effect building a real-time reconciliation engine. This is expensive, fragile, and never quite complete, because there is always some change that arrives out of order or some edge case that leaves the copies disagreeing. The effort produces an approximation of what the single-model architecture provides for free.

The deeper point is that intraday risk is not a feature you buy but a property you inherit from the architecture, or do not. This is why the same capability can be genuinely present on one platform and merely simulated on another that shows a similar screen. When intraday risk is inherited from a single model with an event-driven core, it is trustworthy and cheap; when it is simulated on top of a many-model platform, it is approximate and expensive to maintain. The buyer’s job is to tell the two apart, which is done by asking about the data path behind the screen, not by admiring the screen.

The evaluation question that separates real intraday risk from a refreshing screen is about the data path, not the display: does the intraday risk number read from the same governed positions the overnight batch uses, or from a separate copy? Ask the vendor to explain, concretely, where the intraday number comes from. A confident, specific answer describing one shared model is what you want; an answer about synchronisation, feeds, or near-real-time copies is a description of the many-model architecture wearing an intraday screen.

The overnight batch is the heartbeat of a legacy operation, and its tyranny is easy to underestimate. Every number the business relies on in the morning, position, profit and loss, risk, must wait for the batch to complete. When the batch runs long, the morning is delayed. When the batch fails, the day starts in crisis, with a team scrambling to rerun it before the desk needs its numbers. The batch window constrains everything around it: how late trades can be booked, how early reports can be produced, how much data the platform can hold before the batch no longer fits the night.

As a business grows, the batch window becomes a hard constraint. More trades mean a longer batch, and the batch cannot exceed the night. Eventually the operation is optimising the batch, cutting scope, adding hardware, tuning queries, not to gain anything but to keep fitting the same work into the same window. A cloud-native platform that processes events continuously has no batch window to defend. It scales by processing more events, elastically, rather than by fitting more work into a fixed night, which removes a constraint the legacy operation has learned to live with as if it were a law of nature.

The batch window also shapes the human rhythm of the operation in ways that outlast any single system. Operations teams organise their days around the batch: the late shift that books the last trades before cutoff, the early shift that checks the batch completed, the escalation path for when it did not. These routines are so embedded that they come to feel like the natural shape of running a trading business, when in fact they are the shape of running a batch-bound one. An operation that moves to a continuous architecture often finds it must consciously dismantle routines that no longer have a reason to exist.

Batch failures deserve particular attention in a current-state assessment, because they reveal the fragility the architecture imposes. Ask how often the batch fails, how long a failure takes to resolve, and what the business cannot do while it is being fixed. In many legacy operations the answers are uncomfortable: failures are not rare, resolution can take hours, and the desk starts the day blind while the batch is rerun. A continuous architecture has no equivalent single point of daily failure, because there is no monolithic batch to fail; work flows continuously, and a problem affects a stream of events rather than the whole morning.

During a current-state assessment, quantify your batch: how long is the window, how often does it overrun or fail, what cannot happen until it completes, and how much room is left before growth breaks it? These numbers describe a constraint that a continuous architecture would remove entirely. A platform with no monolithic batch has no batch window to overrun, no nightly single point of failure, and no ceiling on how much data it can process in a night, because it does not process in nights at all.

The headline that dominates early conversations, the licence or subscription price, is a small fraction of what a platform actually costs over its life. The structural difference between cloud-native and legacy shows up most starkly in the categories that a price comparison ignores: infrastructure, operations, change, and the cost of risk. A legacy platform carries hardware and its refresh cycle, a larger specialist support team, expensive change because every modification is a development project, and the ongoing cost of reconciliation and the errors that fragmented data produces. A cloud-native platform removes the hardware, runs with a leaner team, absorbs change through configuration, and reconciles by construction.

The result is that a legacy platform often shows a lower headline licence but a higher total cost over ten years, once the whole picture is counted, while a cloud-native platform often shows a higher subscription but a lower total. The only way to see this is to model the full cost, which is exactly what the total-cost-of-ownership comparison accompanying this handbook is built to do. Comparing headline prices alone systematically favours the more expensive option.

The ten-year view also exposes a timing asymmetry that flatters legacy platforms in the first year and punishes the buyer later. On-premises costs are front-loaded and then recur: the hardware and implementation hit early, and the operations, refresh, and change costs accumulate quietly for a decade. A subscription is level, or grows gently with use. A comparison made in year one, when the on-premises hardware is capitalised and the subscription looks like pure cost, favours legacy; the same comparison made over ten years usually reverses, because the accumulated operational and change costs of legacy overtake the level subscription.

This is why the discount rate and the horizon matter so much in the total-cost model, and why they should be set deliberately rather than left at a default. A short horizon and a high discount rate weight the early years, favouring the option with lower up-front cost, which is often legacy. A ten-year horizon at a realistic cost of capital weights the whole life of the platform, which is the honest basis for a decision the organisation will live with for a decade. The accompanying model exposes these assumptions so the comparison can be made on terms the board can see and defend.

Insist on a ten-year total-cost comparison rather than a price, and set the horizon and discount rate deliberately before you begin, because those two choices largely determine which option looks cheaper. Populate every category, licence, infrastructure, operations, change, reconciliation, and the cost of risk, not just the ones on the invoice. The accompanying total-cost model structures this so the comparison is complete and the assumptions are visible, which is what lets the board see past the headline price to the real cost.

Beyond the total, the shape of the cost differs, and the shape matters. A legacy on-premises platform is largely a capital expenditure: hardware is bought up front and depreciated, licences are paid in large instalments, and the implementation is a major project capitalised over years. A cloud-native platform delivered as a service is largely an operating expenditure: a subscription paid as it is used, scaling with the business rather than bought ahead of it. Which shape suits an organisation depends on its financial circumstances, but the difference is worth understanding rather than stumbling into.

The operating-expenditure model has a particular advantage for a growing or uncertain business: cost tracks use, so there is no large bet made up front on a capacity that may or may not be needed. The capital model commits the organisation to hardware and licences sized for an expected future, and if that future does not arrive, the capacity is stranded. The subscription model trades a lower commitment for a per-unit price that may be higher at scale, which is a genuine trade-off rather than a free lunch, and the total-cost model helps you see where the crossover lies for your own volumes.

The expenditure shape also interacts with how a business grows. A capital model requires the organisation to buy capacity ahead of need, sizing the hardware for the peak it expects to reach, which means paying for headroom that sits idle until the business grows into it, or, worse, discovering that the growth exceeded the guess and the hardware must be replaced early. An operating model lets capacity follow the business, so a firm that grows pays more as it grows and a firm that shrinks pays less, without either having made a large irreversible bet on a forecast that may prove wrong.

There is a governance dimension too. Capital expenditure is scrutinised as a project, approved once, and then largely invisible until the next refresh, which can hide the true running cost of a legacy platform inside a depreciation schedule. Operating expenditure is visible every period, which some organisations dislike but which has the merit of keeping the real cost of the platform in view. A buyer should be aware that the apparent cheapness of a capitalised on-premises platform is partly an artefact of how the cost is accounted for, not only of the cost itself.

Ask your finance function which expenditure shape suits the business, and model both, because the answer is not obvious and depends on your circumstances. A growing or uncertain business often benefits from cost that tracks use; a stable one with cheap capital and a strong infrastructure team may weigh the trade-off differently. The point is to choose the shape consciously against your own situation rather than inheriting whichever shape the deployment model happens to impose.

Beneath the licence sits a category that on-premises buyers routinely underestimate: the cost and effort of running the platform at all. A legacy on-premises deployment needs servers, storage, networking, and the people to operate them, sized for the peak load even though most of the time that capacity sits idle. It needs a refresh cycle, so the hardware is bought again every few years. It needs patching, capacity planning, and out-of-hours cover. None of this creates any trading advantage; it is pure cost of keeping the lights on, and it scales with the size of the operation rather than shrinking as the platform matures.

A cloud-native platform delivered as a managed service moves almost all of this off the customer’s books. Compute is elastic, so the heaviest overnight risk run can borrow capacity it releases by morning, and the customer pays for what it uses rather than for a permanent peak. Patching, capacity, and operations are the provider’s responsibility, amortised across every customer. The trading business is left to trade rather than to run a data centre, and the specialist infrastructure team it once needed can be redirected or retired.

It is instructive to enumerate what running an on-premises platform actually involves, because the list is longer than buyers expect. Beyond the servers themselves there is storage and its growth, networking and its security, operating systems and their patching, databases and their tuning, backups and their testing, monitoring and its alerting, capacity planning and its forecasting, and the out-of-hours cover that a trading platform demands because a failure at any hour stops the desk. Each item needs people with specific skills, and those people must be recruited, retained, and covered when they are on leave.

None of this expertise is a source of competitive advantage; every trading business that self-hosts must build the same undifferentiated capability. This is precisely the kind of work that a managed service amortises across all its customers, doing once what each on-premises operation must do for itself. The question a buyer should ask is not whether their team could run the platform, since a capable team can, but whether running it is the best use of that team, given that the capability creates no edge and consumes people who could be working on things that do.

List everything your team would have to do to run the platform in-house, from patching to out-of-hours cover, and ask honestly whether doing it is the best use of those people. A capable team can run a platform; the question is whether running it, an undifferentiated capability that creates no edge, is worth their attention when a managed service would do it for them. The list is usually longer than expected, and seeing it in full often reframes the build-versus-managed decision.

Trading workloads are spiky. Intraday valuation is light and continuous; the overnight value-at-risk, counterparty exposure, and scenario runs are heavy and periodic. On fixed on-premises hardware, the heavy runs dictate the size of the whole estate: you must own enough capacity for the peak, even though it sits idle most of the time. Elastic compute breaks this. The heavy runs borrow capacity on demand and release it afterward, so the business pays for the peak only while it needs it, and the whole book can be stressed within the operational window rather than sampled because the hardware cannot cope.

Scale, too, works differently. A legacy platform scales by buying bigger hardware, a step change that is planned, capitalised, and disruptive, and that must be sized for a future guessed in advance. A cloud-native platform scales by using more of an elastic resource, smoothly and on demand, so growth does not require a hardware project. For a business whose volumes grow or fluctuate, this difference between smooth elastic scale and step-change hardware scale is one of the clearest practical advantages of the cloud-native architecture.

Elastic compute changes not only the cost of the heavy runs but what is possible within the operational window. On fixed hardware, the overnight risk suite is a compromise: the number of scenarios, the granularity of the simulation, and the frequency of the runs are all constrained by the capacity that can be afforded and the time the batch can take. With elastic compute, these constraints loosen, because capacity can be summoned for the run and released after. A firm can run more scenarios, at finer granularity, more often, not because it bought more hardware but because it can borrow capacity precisely when the run needs it. Better risk management is a direct consequence.

Elasticity also removes a planning burden that consumes real management attention on legacy platforms: capacity forecasting. On owned hardware, someone must predict the peak load a year or more ahead and buy for it, over-provisioning to be safe and still risking a shortfall if the business grows faster than expected. Elastic compute turns this fraught forecast into a non-issue, because capacity follows demand automatically. The saving is not only the idle hardware avoided but the planning effort and the risk of guessing wrong, both of which quietly cost a legacy operation more than its balance sheet shows.

Ask each platform how it handles the heaviest run, the overnight risk suite at full scenario count, and whether that run is constrained by owned hardware or served by elastic capacity. Then ask what better risk management you could do if the constraint were removed: more scenarios, finer granularity, more frequent runs. Elastic compute does not only lower the cost of the heavy runs; it lifts a ceiling on how well you can measure risk, and that lifted ceiling is worth naming in the evaluation.

Over a decade, a trading business changes constantly: new commodities, new instruments, new markets, new products, new reports, new regulations. How cheaply a platform absorbs that change is one of the largest determinants of its lifetime value, and it is decided by architecture. On a cloud-native platform built on one extensible model, adding a commodity or a report is typically a configuration change the organisation can make itself, in days. On a legacy platform, the same change is often a development project requiring the vendor, taking months, because the change must be made and reconciled across several models.

This difference compounds. A business that can change in days moves at the speed of its strategy; a business that must wait months for each change moves at the speed of its vendor’s development queue. Over ten years and hundreds of changes, the gap between the two is enormous, and it rarely appears in a feature comparison because both platforms can, eventually, make any given change. The question is not whether but how cheaply and how quickly, and that is an architectural property.

The compounding of change agility deserves a concrete illustration. Imagine two businesses that each need to make one hundred changes over a decade: new markets, instruments, reports, and regulatory adjustments. The cloud-native business makes most of these itself by configuration, in days, at low cost. The legacy business raises each as a request to its vendor, waits in a queue, pays for development, and tests a release, taking months and real money per change. After a hundred changes the cloud-native business has adapted a hundred times while the legacy business is still working through its backlog, and the gap in responsiveness has become a gap in competitiveness.

Change agility also determines who controls the pace of the business. When change is configuration the business owns its own tempo: it decides what to change and does it. When change is a development project the vendor owns the tempo, because every change waits in the vendor’s queue behind every other customer’s requests. This loss of control is rarely quantified in a selection, because it is not a line item, but it is one of the most consequential differences between the architectures. A business that cannot change without its vendor’s cooperation is not fully in control of its own strategy.

Take the changes you actually foresee over the next few years, new markets, instruments, reports, regulations, and ask each platform which of them it could handle by configuration and which would require the vendor to develop. The ratio of configuration to development in that list predicts your future agility and cost more reliably than any general claim of flexibility. A platform that turns your foreseeable changes into configuration puts you in control of your own tempo; one that turns them into development projects hands that control to its queue.

Not all change is equal, and it helps to distinguish three kinds. Configuration is change the platform anticipates: adding a commodity, a curve, a report, a workflow, within the model the platform already supports. Extension is change the platform did not anticipate but allows, through an API or a plugin, without modifying the platform itself. Customisation is change to the platform’s own code, which a good architecture avoids because it creates a version that must be maintained separately forever. A cloud-native platform aims to make most change configuration, some change extension, and customisation rare or impossible; a legacy platform often makes even routine change into customisation.

This distinction bears directly on lock-in. Customisation is the deepest form of lock-in, because the customised version cannot be upgraded easily and cannot be moved. Configuration and extension are lighter, because they sit in supported layers that survive upgrades and, in principle, could be recreated elsewhere. When evaluating a platform, ask how much of the change you foresee will be configuration, how much extension, and how much customisation, because the answer predicts both your agility and your degree of lock-in over the life of the platform.

The configuration-extension-customisation distinction gives a buyer a precise question to ask of any requirement: which of the three would meeting it require on this platform? If a platform can meet a novel requirement by configuration, that is ideal. If it needs an extension through a supported API, that is acceptable and durable. If it demands customisation of the platform’s own code, that is a warning, because the customisation will complicate every future upgrade and deepen lock-in. Running your foreseeable requirements through this test during evaluation predicts your future agility more reliably than any feature checklist.

Lock-in is not binary but a spectrum, and the architecture largely fixes where a platform sits on it. A platform whose adaptations live in configuration and supported extensions leaves the customer relatively free: the adaptations survive upgrades and could, in principle, be rebuilt elsewhere. A platform that requires customisation of its code binds the customer tightly, because the customised version is expensive to upgrade and effectively impossible to move. Evaluating lock-in means asking not only about data portability and contract terms but about how deeply the platform’s architecture will entangle your adaptations with its code.

Run your requirements through the configuration-extension-customisation test explicitly during evaluation, and treat any requirement that demands customisation of the platform’s code as a warning about both agility and lock-in. Ask the vendor how upgrades handle configuration, extension, and customisation respectively. A platform that preserves your configuration and extensions through upgrades, and rarely needs customisation, is one that stays current without re-doing your work, which is the property you want for a decade.

Underneath the cloud-versus-legacy difference is a question about data: is there one governed model of the business, or several copies? A governed data model is one authoritative representation of each fact, the trade, the position, the curve, the counterparty, with defined ownership, quality rules, and lineage. Every function reads and writes this model, so the data is consistent by construction. The governed model is the foundation on which the reconciliation-free, intraday, trustworthy operation stands, and its absence is the foundation of the reconciling, batch-bound, distrustful one.

Governance is not bureaucracy here; it is what makes the single model usable. Ownership defines who is responsible for each domain of data. Quality rules define what a valid record looks like, enforced as the data is written rather than discovered later. Lineage records where each value came from, so any number can be traced to its inputs. Master data provides golden sources for reference data, counterparties, instruments, calendars, so that everyone means the same thing by the same term. These disciplines turn a single store into a governed model, and they are far easier to apply to one model than to several copies.

The governed model is where several of this handbook’s themes converge, because it is the common cause of reconciliation-free operation, intraday risk, reproducibility, and trustworthy analytics. Each of these is not a separate feature to be bought but a consequence of having one authoritative, governed representation of the business. This is why architecture is more predictive than features: a platform with a genuine governed model tends to have all of these properties together, because they share a root, while a platform without one tends to lack them together, however many individual features it lists.

Governance also determines whether the single model stays trustworthy as it grows. A single store without governance can degrade into a single mess: inconsistent reference data, unowned domains, quality problems discovered too late. What keeps the model trustworthy is the discipline around it, clear ownership, quality rules enforced on write, lineage maintained, master data curated. A buyer evaluating a platform’s data architecture should probe not only whether there is one model but whether that model is governed, because an ungoverned single model can drift toward the same distrust as a many-model system, by a different route.

Probe not only whether a platform has one model but whether that model is governed, because an ungoverned single store can drift toward the same distrust as a many-model system. Ask who owns each data domain, how quality rules are enforced, whether lineage is maintained, and how master data is curated. The presence of these disciplines is what keeps the single model trustworthy as it grows, and their absence is a quieter path to the same reconciliation problems by a different route.

A governed model that only holds the current state is not enough for a trading business, because so many questions are about the past. What was the position on the day of the dispute? What was the book worth at the moment of the default, on the curve that was live then? What did the report say when it was filed, before the later correction? Answering these requires bitemporality: tracking both when a fact was true in the world and when the system recorded it, so any past state can be reproduced exactly. Bitemporality is invisible in a demonstration and decisive in an audit, a dispute, or a regulatory examination.

A cloud-native platform designed around a governed model typically builds bitemporality in, because it is far easier to design in than to add later. A legacy platform assembled from modules often cannot reproduce a past state exactly, because the modules overwrote it or recorded it inconsistently, and reconstructing it becomes a forensic exercise. When evaluating a platform, ask it to reproduce a valuation as of a past date on the data that was live then. The ease or difficulty of that request reveals whether reproducibility is a property of the architecture or a hope.

The value of reproducibility is easiest to appreciate at the moments it is tested, which are always adversarial. A counterparty disputes a settlement and the business must show exactly what the trade and the curve were on the relevant date. A regulator examines a historical report and asks how the numbers were derived. An auditor questions a valuation and wants it reconstructed as it stood. In each case the business needs to reproduce a past state precisely, on the data that was live then, and a platform that cannot do this leaves the business reconstructing history by hand, or unable to reconstruct it at all, at exactly the moment when being wrong is most costly.

Bitemporality is hard to add later because it touches how every fact is stored. A platform that recorded only the current state overwrote its history, and no amount of later engineering can recover what was not kept. This is why reproducibility must be tested during evaluation rather than assumed: ask the platform to reproduce a specific past valuation and watch whether it can do so directly, from retained history, or whether it must reconstruct the answer through effort and approximation. The difference reveals whether the architecture keeps its history as a matter of design or discards it as a matter of course.

Ask any platform to reproduce a specific valuation as of a past date, on the market data that was live then, and watch how it responds. A platform built on a bitemporal governed model does this directly, from retained history. A platform that overwrote its history reconstructs the answer through effort and approximation, or cannot produce it at all. Because reproducibility is decisive exactly when it is tested, in audits, disputes, and examinations, testing it during evaluation rather than assuming it is one of the most valuable checks you can make.

No ETRM lives alone. It must exchange data with market data providers, exchanges and clearing houses, the general ledger and ERP, credit and collateral systems, confirmation and matching services, regulatory reporting, and the data warehouse. How a platform integrates with this landscape is a large part of its real cost and value, and here too the architectures differ. A cloud-native, API-first platform exposes every capability as a governed, versioned interface, so integrations are clean, supported, and durable. A legacy platform often integrates through files and database-level access, which are brittle, hard to version, and prone to breaking when either side changes.

The difference shows up over time. API-first integrations built against versioned interfaces keep working as the platform evolves, because breaking changes are managed and old versions supported. File and database integrations tend to shatter on upgrade, because they depend on internal details that were never meant to be an interface. A landscape of brittle integrations becomes a barrier to changing anything, because every change risks breaking a hidden dependency, whereas a landscape of versioned API integrations can evolve safely. Integration architecture, in other words, determines how freely the whole estate can change.

The integration layer is where a platform’s architecture meets the messy reality of an existing estate, and it is often where a nominally modern platform reveals a legacy heart. A platform may present a clean front-office experience and still integrate with everything around it through overnight files and direct database access, because that is how its modules were always connected. The buyer should look past the demonstration to the integration mechanisms: how does the platform actually exchange data with the ledger, the market-data feed, the clearing house, the warehouse? The answer often reveals more about the architecture than the user interface does.

There is a strategic dimension to integration architecture beyond durability. A platform whose capabilities are all reachable through governed APIs can participate in an event-driven estate, emit and consume events, and be composed with other systems and with your own code. A platform reachable only through files and database access can be connected but not truly composed; it sits in the estate as an island that data is shipped to and from. As trading businesses increasingly want to build their own edge on top of their platforms, this difference between a composable platform and a connectable one becomes a difference in what the business can build.

Look past the user interface to the integration mechanisms: ask concretely how the platform exchanges data with your ledger, your market-data feed, your clearing house, and your warehouse. Files and direct database access reveal a legacy heart however modern the front office looks; governed, versioned APIs reveal an architecture built to compose. Because integration architecture determines how freely your whole estate can change, this is one of the most consequential and most overlooked areas to probe.

An ETRM outage stops trading, so resilience is a business-continuity requirement, not a technical nicety. Here too the architectures differ structurally. A cloud-native platform is typically deployed across multiple availability zones or regions, with data replicated and failover tested regularly, and because the environment is defined as reproducible infrastructure, it can be recreated rather than merely restored. A legacy platform’s resilience usually rests on its own data centre and a recovery site, with recovery objectives that are longer and, too often, a recovery plan that has never been fully exercised.

The decisive question for either is whether recovery has actually been tested. A disaster-recovery plan that has never been exercised is a hypothesis, not a capability, and in a crisis the difference is everything. Cloud-native platforms, operated as managed services, tend to test failover as a matter of routine; legacy platforms, recovered by hand, tend to discover the gaps in their plans only when they are needed. Ask any platform not for its recovery objectives but for the date of its last successful recovery test.

Resilience is one of the areas where the managed-service model most changes the buyer’s position, because it moves responsibility for a demanding capability to a party that provides it at scale. Building multi-region resilience for an on-premises platform is a major undertaking: a second site, continuous replication, tested failover, and the people to run it, all for an event that, if the plan works, never happens. A managed cloud-native platform provides this as part of the service, engineered once and shared across every customer, which is usually both more robust and cheaper than each customer building it alone.

The uncomfortable truth about disaster recovery is that most plans are less ready than their owners believe, because they are rarely tested under realistic conditions. A plan that has been written, approved, and filed is not a capability; only a plan that has been exercised, ideally without warning, has been shown to work. This is why the single most revealing question a buyer can ask about resilience is not about objectives or topology but about the date and outcome of the last real failover test. A platform that tests routinely will answer confidently; one that does not will change the subject.

Do not ask a platform for its recovery objectives; ask for the date and outcome of its last real failover test. Objectives on paper are hypotheses; a recent, successful, realistic test is evidence. A managed cloud-native platform that tests failover routinely will answer with a date and a result. A platform that has never fully exercised its recovery plan will deflect, and that deflection tells you the resilience is aspirational, whatever the topology diagram shows.

Resilience is usually discussed in terms of two objectives. The recovery time objective is how quickly the platform must be back after a failure; the recovery point objective is how much data, measured in time, the business can afford to lose. These objectives should be set by the business according to what an outage costs, not by the technology according to what is convenient. A trading business typically needs a short recovery time, because it cannot trade while the platform is down, and a near-zero recovery point, because losing trades is unacceptable.

The architecture determines how affordably these objectives can be met. Meeting a short recovery time and a near-zero recovery point on legacy on-premises infrastructure requires a hot standby site, continuous replication, and regular tested failover, all of which the customer must build and operate. A cloud-native platform delivered as a managed service typically meets tight objectives as part of the service, with multi-region replication and routine failover testing built in. The buyer should ask not only what the objectives are but who is responsible for meeting them and how often failover is actually tested.

Setting recovery objectives well requires the business and the technologists to have an honest conversation that is often skipped. The business must say what an outage actually costs, in trading opportunity, in settlement failures, in regulatory breach, and how much data loss is truly tolerable, which for most trading operations is very little. The technologists must say what meeting those objectives requires and costs. When this conversation does not happen, objectives are set by default or by what the current technology happens to provide, which means the business is accepting a level of risk it never consciously chose.

The gap between stated and tested objectives is where resilience most often fails. A platform may have a recovery time objective of an hour on paper and take a day in practice, because the plan that would achieve the hour has never been exercised and the gaps only appear under real conditions. This is why objectives should be treated as claims to be verified, not specifications to be trusted. Ask not only what the objectives are but for evidence, from an actual test, that they can be met, and treat an objective that has never been demonstrated as an aspiration rather than a fact.

Have the honest conversation about recovery objectives before you evaluate platforms: what does an outage actually cost the business, and how much data loss is truly tolerable? Set the objectives from those answers, then treat every platform’s claimed objectives as claims to be verified with evidence from an actual test. An objective that has never been demonstrated is an aspiration; insist on the demonstration, because a trading business discovers the gap between claimed and real recovery at the worst possible moment.

Security is sometimes cited as a reason to keep a platform on-premises, on the intuition that data held in your own building is safer. For most organisations the opposite is now true. A serious cloud provider invests more in physical and network security, patching discipline, and independent certification than an individual trading business can justify, and it submits to audits such as SOC 2 and certifications such as ISO 27001 that few in-house data centres could pass. The relevant question is not where the data sits but whether the controls around it are strong, tested, and independently attested.

The cloud-native model also improves the compliance posture in ways that matter to a regulated trading business. Access is governed centrally and consistently; changes are logged; the platform’s controls are documented and certified rather than assembled ad hoc. A legacy on-premises platform can be made secure, but the burden of proving it, continuously, to auditors and regulators falls entirely on the customer. The one genuine exception is data residency, addressed in the next chapter, where law requires data to remain within a jurisdiction.

The security conversation benefits from separating three distinct questions that are often conflated. First, is the platform itself secure, in its code, its access model, and its controls? Second, is the infrastructure it runs on secure, in its physical, network, and operational protections? Third, is all of this independently verified, or merely asserted? A serious cloud-native platform delivered as a managed service can usually give strong, evidenced answers to all three, backed by certifications like SOC 2 and ISO 27001. An on-premises platform inherits the second question from the customer’s own data centre, which is rarely certified to the same standard, and the third from whatever assurance the customer can produce.

The regulatory posture follows from the same architecture. A platform with centralised, consistent access control, comprehensive logging, and certified controls makes it far easier to demonstrate compliance to a regulator, because the evidence is a property of the system rather than a report assembled under pressure. A legacy platform with access controls spread across modules and assurance assembled by hand makes every examination a project. For a regulated trading business, the difference between compliance that is evidenced by the architecture and compliance that must be demonstrated by effort is a recurring saving in time, cost, and regulatory risk.

Separate the three security questions when you evaluate, is the platform secure, is its infrastructure secure, and is all of it independently verified, and ask for the certifications that answer the third. SOC 2 and ISO 27001 turn security from an assertion into evidence. Then ask how the platform makes compliance demonstrable to a regulator: centralised access, comprehensive logging, certified controls. Security you can evidence and compliance you can demonstrate are recurring savings for a regulated business, not one-time checkboxes.

There is one security-related consideration that genuinely favours controlled deployment: data residency and sovereignty. Some jurisdictions require that certain data remain physically within their borders, or prohibit it from being accessible to foreign authorities. Where such rules apply, deployment topology must respect them, and this is a legitimate constraint rather than a preference. It is important, though, to distinguish a genuine legal residency requirement from a general unease about the cloud, because the two lead to very different decisions.

A portable cloud-native architecture usually accommodates residency through regional deployment: the same platform runs in a data centre or cloud region within the required jurisdiction, keeping the data local while preserving the architecture. This is very different from concluding that residency requires an on-premises legacy platform. The buyer with a real residency requirement should ask a cloud-native vendor how it meets residency through regional deployment, rather than assuming residency and cloud-native are incompatible. Often they are not.

Residency requirements repay careful analysis rather than blanket assumptions, because they are usually more specific than they first appear. A rule may require that certain personal data remain in a jurisdiction while placing no constraint on trade data, or may permit data to leave provided it is encrypted and controlled. Understanding exactly what must stay where, and why, often reveals that the requirement can be met by deploying the platform in a region within the jurisdiction, rather than by rejecting the cloud altogether. The mistake is to treat a specific residency rule as a general prohibition on cloud-native architecture.

The portability of a well-designed cloud-native platform is precisely what lets it meet residency without sacrificing its architecture. Because the platform is defined as reproducible infrastructure, it can be stood up in whichever region the law requires, keeping the data local while preserving the single model, the elasticity, and the managed operation. This is a genuine advantage over both a rigid cloud platform that runs only in certain regions and a legacy platform that meets residency by being pinned to one data centre at the cost of everything else. Residency, properly understood, is a deployment question, not an architecture question.

If you have a residency requirement, analyse exactly what must stay where and why, rather than treating it as a blanket prohibition on the cloud. Then ask cloud-native vendors how they meet residency through regional deployment. Often a specific residency rule is satisfied by running the platform in a region within the jurisdiction, keeping the data local while preserving the architecture. Residency, examined precisely, is usually a deployment question a portable cloud-native platform can answer, not a reason to accept a legacy one.

The way a platform serves analytics and reporting follows directly from its data architecture. A cloud-native platform with a governed model materialises analytical marts over the same data the operation runs on, with conformed dimensions and a semantic layer, so business intelligence runs on trusted data with lineage back to the trade. A legacy platform, with several models, typically exports nightly to a separate warehouse and reconciles before anyone trusts the numbers, which reintroduces the copy-and-reconcile problem in the analytical layer.

The consequence is a difference in trust. When analytics run on a governed projection of the operational data, the boardroom report and the operational reality agree by construction, and lineage lets any figure be traced to its source. When analytics run on a nightly export, the report can differ from the operation, and the organisation is back to reconciling and to distrusting its own numbers, now at the level of management information. Keeping analytics on the same governed data preserves the single-version-of-the-truth property all the way through to the board.

The analytics architecture is where the single-model advantage reaches the people who most influence strategy: executives and the board. When the management information they see is a governed projection of the operational data, they are looking at the same reality the desk trades against, and any figure can be traced back to the trades beneath it. When the management information comes from a nightly export that has been reconciled and adjusted, they are looking at a copy that may differ from the operation, and the organisation spends effort explaining the differences. The architecture of the analytical layer thus shapes whether leadership trusts its own numbers.

There is a productivity dimension too. On a platform where analytics run on the governed model, a new report or a new analysis is largely a matter of querying data that is already trusted and defined. On a platform that exports to a warehouse, every new analysis must first navigate the export, the transformations, and the reconciliation, and must establish that its numbers agree with the operation before anyone will rely on them. The single-model architecture therefore does not only make analytics more trustworthy; it makes producing them faster, because the trust is inherited from the governed data rather than re-established for each report.

Ask how a new report or analysis is produced: does it query the governed model directly, or must it navigate an export, transformations, and a reconciliation before anyone trusts it? The answer reveals whether analytics inherit trust from the operational data or must re-establish it each time. A platform whose analytics run on a governed projection of the same data gives leadership numbers that match the operation by construction, and gives analysts a faster path to any new question.

How a platform is upgraded is a quiet but important difference. A legacy on-premises platform is typically upgraded in big-bang events: a major version, planned for months, tested laboriously, and cut over in a high-risk weekend, often years apart because each upgrade is so painful. Between upgrades the platform ages, and the gap between the customer’s version and the current one widens, until the eventual upgrade is a project in its own right. Customisations make this worse, because each must be re-applied and re-tested against the new version.

A cloud-native platform delivered as a service is upgraded continuously and incrementally, in small, low-risk changes deployed frequently, so the customer is always on a current version and never faces a big-bang upgrade. Because change is configuration and extension rather than customisation, upgrades do not break the customer’s tailoring. This continuous-delivery model is only possible on an architecture designed for it, and it removes one of the largest recurring costs and risks of the legacy model: the periodic, perilous, expensive upgrade.

The upgrade model has a compounding effect on the health of a platform over its life. A continuously delivered platform is always current, so it never accumulates a backlog of unadopted improvements and never faces the cliff of a major version migration. A big-bang platform ages between upgrades, and because each upgrade is painful, organisations defer them, widening the gap until the platform is several versions behind and the eventual upgrade is a major project. Deferred upgrades also mean deferred security patches and deferred improvements, so the cost of the big-bang model is not only the upgrade projects but the accumulated risk of running old software.

Customisation and upgrades interact to create one of the most expensive traps in the legacy model. Each customisation of the platform’s code must be re-applied and re-tested against every new version, so a heavily customised platform becomes progressively harder to upgrade, which encourages further deferral, which widens the version gap, which makes the eventual upgrade harder still. Organisations can find themselves effectively frozen on an old version because upgrading would mean redoing years of customisation. The continuous-delivery model avoids this trap by keeping adaptation in configuration and extension that survive upgrades, so the platform can stay current without re-doing the customer’s work.

Ask how the platform is upgraded, how often, and what happens to your configuration and any customisation when it is. Continuous, incremental delivery that preserves your adaptations keeps you current without projects or risk. Periodic big-bang upgrades that require re-applying customisation are a recurring cost and a trap that can freeze you on an old version. The upgrade model is a quiet question with a decade of consequences, and it is worth asking early rather than discovering later.

For most organisations the cloud-versus-legacy decision is not greenfield; it is a question of whether and how to migrate off an incumbent. Migration is where the risk of the decision concentrates, and it deserves the same rigour as the selection itself. The governing principle is to migrate in stages against a clear target, not to attempt a big-bang cutover of everything at once. Assess the source data honestly, cleanse and de-duplicate it, transform it to the target model, load it, and reconcile before anyone relies on it, and prove the new platform in parallel with the old before switching off the old.

The most common migration failure is underestimating the state of the source data. Years of workarounds, free-text fields, and undocumented conventions accumulate in a legacy platform, and they surface as breaks during migration if they are not assessed first. Budget for data quality work explicitly, run a parallel period long enough to build trust, and define the go and no-go criteria for cutover before emotion enters the room. The migration-readiness assessment accompanying this handbook turns these principles into a scored checklist.

Migration is as much an organisational undertaking as a technical one, and the organisational side is where it most often struggles. The people who operate the legacy platform hold undocumented knowledge of its conventions and workarounds; the desk depends on its familiar screens and reports; the back office has built routines around its rhythms. A migration that treats these only as technical data-mapping problems, and neglects the training, the reassurance, and the change management, can deliver a technically correct new platform that the organisation resists. Budgeting for the human transition is as important as budgeting for the data.

The parallel run is the heart of a safe migration, and it is worth understanding why it is so effective. Running the old and new platforms together, on the same trades, lets the organisation compare their outputs directly and build confidence that the new platform is correct before relying on it. Discrepancies surface while the old platform is still authoritative, so they can be investigated without risk. The parallel run costs real effort, because everything is done twice for a period, but it converts the terrifying question of whether the new platform is right into a series of concrete comparisons, which is exactly what a high-stakes migration needs.

Before committing to a migration, assess your readiness honestly across data quality, integration, operating model, and cutover planning, and budget explicitly for the human transition, not only the data. The migration-readiness assessment accompanying this handbook scores these categories so the gaps are visible before they become crises. A migration succeeds or fails largely on preparation, and the most common failure, underestimating the state of the source data, is exactly the one a candid readiness assessment surfaces first.

There is no single right way to sequence a migration, but there are recognisable strategies with known trade-offs. A big-bang cutover moves everything at once: fast in principle, but high-risk, because everything depends on a single moment going well. A phased migration moves the operation in stages, by business, commodity, or function, reducing risk at the cost of running two platforms in parallel for a period. A parallel run operates the old and new platforms together until the new one is trusted, then retires the old, which is the safest and also the most effortful, because everything is done twice for a while.

The right strategy depends on the operation’s tolerance for risk and its capacity to run in parallel. Most large migrations favour a phased approach with a parallel run for each phase, accepting the extra effort as the price of controlling risk, because the cost of a failed cutover in a trading business is far higher than the cost of running two systems for a while. Whatever the strategy, the sequencing should be planned against dependencies, migrating the foundational data and functions first and the dependent ones after, so that each phase stands on solid ground.

Choosing a migration strategy is largely a matter of matching the approach to the organisation’s appetite for risk and its capacity to run two systems. A firm with a low tolerance for disruption and the resources to run in parallel should phase and parallel-run, accepting the extra effort as insurance. A firm under time pressure with a simpler operation might accept more risk for speed. The strategy is a deliberate trade-off, and it should be chosen consciously against the specific circumstances rather than defaulted to whatever the vendor proposes, because the vendor’s incentives and the customer’s are not always identical on this point.

Sequencing within a phased migration should follow the dependencies in the data and the operation. Foundational reference and master data must move first, because everything depends on it; then the core trade and position data; then the functions that build on them. Attempting to migrate a dependent function before its foundations are in place produces a phase that rests on incomplete data and generates breaks that are hard to diagnose. A dependency-aware sequence, in which each phase stands on the solid ground of the phases before it, is what keeps a phased migration from turning into a series of avoidable crises.

Choose your migration strategy consciously against your own tolerance for risk and capacity to run in parallel, rather than defaulting to whatever the vendor proposes, whose incentives may differ from yours. Favour a phased approach with a parallel run for each phase unless you have strong reasons otherwise, and sequence the phases by dependency so each rests on solid ground. A deliberately chosen, dependency-aware sequence is what keeps a migration from becoming a series of avoidable crises.

Every migration decision has a counterfactual that is easy to ignore: staying on the legacy platform. This is not a neutral, cost-free option. A legacy platform accrues cost and risk simply by continuing: the hardware ages and must be refreshed, the reconciliation continues, the change queue lengthens, the batch window tightens as volumes grow, and the pool of people who understand the aging system shrinks. Doing nothing feels safe because it avoids the visible risk of migration, but it accepts a growing invisible risk in exchange.

The honest comparison is not migration against a stable status quo but migration against a legacy platform that is itself getting more expensive and more fragile over time. Sometimes the counterfactual is genuinely fine: a well-fitting, fully-amortised platform with years of life left and no pressing constraint. Often it is not, and the cost of doing nothing, compounding quietly, exceeds the cost of migrating. The total-cost model should be run for both the new platform and the continuing legacy one, so the comparison is against reality rather than against an imagined stability.

The counterfactual of staying put deserves the same rigorous costing as the migration itself, because otherwise the comparison is unfair to the point of being misleading. Staying on the legacy platform means continuing to pay for hardware refreshes, reconciliation, expensive change, and the growing cost of maintaining an aging system with a shrinking pool of expertise. It also means continuing to forgo the benefits the new platform would bring, which is a real cost even though it appears on no invoice. A fair decision models the legacy platform’s future cost trajectory, not a flat continuation of today.

There is a risk dimension to doing nothing that is easy to underweight because it is gradual. An aging legacy platform becomes progressively harder to support as the technology ages and the people who understand it retire or leave. The batch window tightens as volumes grow. The accumulated customisations make every change riskier. None of these is a crisis on any given day, but together they describe a platform becoming more fragile and more expensive over time. The risk of doing nothing is not that something breaks tomorrow but that the platform slowly becomes a liability, and the longer the decision is deferred the fewer options remain.

Model the legacy platform’s future, not a flat continuation of today, when you weigh migration against staying, because staying is not cost-free or risk-free. Refreshes, reconciliation, expensive change, a tightening batch window, and shrinking expertise all compound over time. Run the total-cost model for both the new platform and the continuing legacy one, so the comparison is against the legacy platform’s real trajectory rather than against an imagined stability that will not hold.

This handbook is not an argument that cloud-native is always the answer. There are genuine situations where a legacy or on-premises platform remains the right choice, and a fair evaluation names them. Strict data-residency or sovereignty rules in some jurisdictions may require on-premises or private-cloud deployment. An organisation with a large, capable, and already-paid-for infrastructure team may value the control of self-operation. A business with a heavily customised legacy platform that fits its operation well, and no pressing need to change, may find that the cost and risk of migration outweigh the benefits for now.

The honest position is that the cloud-native architecture wins on cost, agility, and resilience for most trading operations most of the time, but the decision should be made against your specific constraints, not a general presumption. The total-cost-of-ownership comparison and the architecture-difference scorecard exist precisely so that the choice rests on your own numbers and your own operating model rather than on a vendor’s framing or a fashionable default.

Naming the cases where legacy is the right answer is not a hedge but a discipline, because a recommendation that admits no exceptions is a sales pitch rather than an analysis. A firm with a genuine, specific data-residency obligation that its candidate cloud providers cannot meet through regional deployment has a real reason to keep control of its infrastructure. A firm whose legacy platform genuinely fits its operation, is fully paid for, and faces no pressing constraint may rightly judge that the cost and risk of migrating outweigh the gain for now. These are legitimate conclusions, reached by applying the frameworks honestly to a specific situation.

What distinguishes a sound decision to stay from mere inertia is that the sound decision is made against the evidence rather than against the discomfort of change. Inertia keeps the legacy platform because migrating is frightening; a sound decision keeps it because the total-cost model and the architecture scorecard, run honestly, show that staying is genuinely better for this operation at this time. The tools accompanying this handbook exist precisely to tell these two apart, so that a decision to stay is one the organisation has actively chosen on the merits rather than one it has drifted into by avoiding the harder question.

Distinguish, honestly, whether your inclination to stay is a sound conclusion from the evidence or inertia in the face of change. Run the total-cost model and the architecture scorecard, and see whether they show staying to be genuinely better for your operation, or whether they show a case for change that discomfort is resisting. A decision to keep a legacy platform is entirely legitimate when the evidence supports it and merely expensive when it does not, and the tools exist to tell the two apart.

Several objections to cloud-native platforms recur, and each contains a grain of truth wrapped around a misconception worth addressing directly. The cloud is less secure: as covered, a serious provider is usually more secure and independently certified, though residency is a real constraint. We will lose control: control shifts from operating the infrastructure to governing the service through contracts and interfaces, which for most businesses is a better use of attention. It is more expensive: the subscription is often higher but the total is usually lower, which only the full model reveals.

Other objections deserve equal candour. Our needs are too specific: specificity is met by configuration and extension on a governed model, and a platform that requires customisation for every specific need is the one to worry about. Migration is too risky: migration is risky, which is why it is staged, parallel-run, and governed, but the risk of migrating is weighed against the compounding risk of not migrating. The point of naming these objections is not to dismiss them but to answer them honestly, so the decision rests on their real weight rather than on their rhetorical force.

Engaging with objections honestly is more persuasive, and more useful, than dismissing them, because each common objection points at a real consideration even when its conclusion is wrong. The security objection rightly insists that security matters, and the answer is not to wave it away but to show that a certified managed service usually provides stronger, better-evidenced security than an in-house data centre, while acknowledging residency as a genuine constraint. Treating the objection seriously and answering it on the evidence builds the confidence that a decision of this size requires.

The most stubborn objection, that our needs are too specific to buy, deserves particular care because it feels true to the people who hold it. Every trading operation does have genuine specificities. The question is whether meeting them requires customising a platform’s code or whether they can be met by configuration and extension on a governed model. In the great majority of cases the specificities are variations the platform can be configured to handle, not fundamental gaps, and a platform that genuinely cannot handle them by configuration is one whose model does not fit the business, which is a reason to look elsewhere rather than to build. The objection, examined, usually turns into a criterion for choosing well.

When an objection to cloud-native arises, engage it on the evidence rather than dismissing it, because each common objection points at something real. Answer the security objection with certifications and the residency nuance; answer the control objection by distinguishing operating infrastructure from governing a service; answer the specificity objection by asking whether the need requires customisation or can be met by configuration. Objections examined carefully usually turn into criteria for choosing well rather than reasons to avoid choosing.

A decision of this size should rest on evidence, not on the impression left by a demonstration or the confidence of a vendor. Bring the threads of this handbook together into a structured comparison: model the full ten-year cost of each option rather than the headline price; score the architectural difference on the dimensions that decide the decade, one model versus many, timeliness, change agility, integration, resilience, and security; and, if migrating, assess your readiness honestly before committing. Each of these is supported by a tool accompanying this handbook, so that the decision is documented and defensible to a board that is right to ask hard questions.

Above all, evaluate the architecture, not the feature list. Both a cloud-native and a legacy platform will tick the functional boxes, because the boxes describe capabilities the whole market has had for years. What separates them is structural, and structure is what determines the cost, the speed, and the trust you will live with for a decade. Use the frameworks and tools here to see past the demonstration to the architecture beneath, and make the choice on your own evidence, against your own constraints, for your own operation.

The structured comparison that concludes a sound decision does more than produce an answer; it produces a defensible answer, which matters because a decision of this magnitude will be questioned. When the total-cost model, the architecture scorecard, and the migration-readiness assessment are all documented, the organisation can show not only what it decided but why, on what assumptions, and against what alternatives. This documentation is what lets the decision withstand the scrutiny of a board, an audit, or a future review, and it is what distinguishes a considered choice from an expensive guess dressed up in confidence.

In the end the discipline this handbook teaches is simple to state and demanding to practise: look past what a platform does to how it does it, and judge the how against the decade you will live with it. The feature list will always be reassuring and always be nearly identical between serious platforms, which is exactly why it is the wrong basis for the decision. The architecture, the single governed model or the reconciled many, the event-driven core or the overnight batch, the configuration or the development project, is what will determine your cost, your speed, and your trust for years. Choose on the architecture, on your own evidence, and the decision will serve you long after the demonstration is forgotten.

Bring the tools together into a documented decision: the total-cost model, the architecture-difference scorecard, and, if migrating, the readiness assessment. Document not only what you decided but why, on what assumptions, and against what alternatives, because a decision of this size will be questioned and should be defensible. Then trust the discipline: judge the architecture, not the feature list, on your own evidence, for your own operation, and the choice will serve you long after the demonstration is forgotten.