The central government property register - delivered in five months
After two competitors won on price and failed to deliver, the Office of Government Property turned to CDS. InSite — a bespoke, modern, GDS-compliant property register for 1,200 public sector organisations — went from contract award to production in five months. It was only possible because of twenty years of domain knowledge.
£5bn
1200
20+ yrs
5
CDS built InSite — a bespoke, modern government property register — from contract award to production in five months, replacing the 20-year-old EPIMS platform it had built and managed since 2005.
The work spans people, process, data and technology: three data-input channels tuned to the diversity of 1,200 organisations, a data model aligned to the Government Property Data Standard from the ground up, API-first access for OGP’s own BI tooling, and a clean break from legacy .NET and on-premise infrastructure.
The five-month window was only achievable because two decades of domain knowledge substituted entirely for the discovery, specification and BA input that would normally precede a project of this scale.
Client
Office of Government Property
Sector
Central Government
Partnership
20+ years
-
Delivered InSite contract-award-to-production in 5 months, before FY end.
-
Replaced a legacy 20-year EPIMS codebase that couldn’t be modernised.
-
Succeeded where two off-the-shelf SaaS procurements had failed.
-
Aligned to the Government Property Data Standard for the first time.
-
Built three input channels — UI, API and bulk import — for 1,200 orgs.
-
Passed a government pen test with low-severity scores; no critical issues.
ORGANISATION PROFILE
Office of Government Property
SITS WITHIN: The Cabinet Office
REMIT: Strategic management of the central government property estate across England
REACH: ~1,200 organisations — departments, local authorities, NHS, defence
ACCOUNTABILITY: The annual State of the Estate Report to Parliament
TRACK RECORD: ~£5bn government asset realisation facilitated over the platform’s life
Stewarding the government estate
OGP sits within the Cabinet Office and is responsible for the strategic management of the entire central government property estate across England — overseeing property data from approximately 1,200 public sector organisations.
Its purpose is to enable government to make informed strategic decisions about that estate: where to sell property to raise capital, where to renegotiate leases, where to relocate staff out of expensive central London locations, and how to optimise the cost and utilisation of publicly owned and leased buildings.
InSite is the latest generation of the platform that underpins this work — a bespoke, modern government property register built by CDS and delivered from contract award to production in five months. It replaces EPIMS, which CDS had built and managed since 2005, and is internally facing, accessible to a defined set of authenticated users across all 1,200 organisations.
At one point its predecessor held what was described as the largest property database in Europe.
The challenge
The challenge facing OGP had accumulated over two decades. EPIMS was built in 2005 and developed iteratively for 20 years, but never fundamentally re-architected. By 2024 it ran on legacy technology, wasn’t aligned to modern government standards, and couldn’t be cost-effectively brought into line with the Government Property Data Standard. Two successive competitors with off-the-shelf SaaS solutions were awarded contracts to replace it — both on price, both failed. The challenge is best understood across four dimensions.
People
Participation, and a capability gap
The platform needed to work across 1,200 public sector organisations, each responsible for submitting and maintaining their own property data. Central government departments were mandated to provide information; local government and quasi-government bodies were encouraged but not required. This created a participation challenge: the platform had to offer genuine value to submitting organisations to encourage engagement.
OGP had pursued a self-service strategy for several years, building internal capability to reduce supplier dependency. But the structural reality of the civil service is that staff move between roles and do not accumulate the same depth of domain expertise as a long-term contractor. Despite sustained effort, OGP still relied on CDS for consultancy on government property policy and data architecture — and there was a capability gap with other suppliers that meant they could not deliver a replacement.
Process
A snapshot only as good as its inputs
The core process challenge was collecting consistent property data from 1,200 organisations — each with its own systems, data management practices, and portfolio characteristics. Because the platform represented a snapshot of the estate at a point in time, delays or incomplete submission directly limited the usefulness of the dataset.
Over time, functionality was added for organisations that wanted the platform to act as a broader property management tool. This expansion gradually turned it into what was described as a “behemoth solution” with many purposes, moving further from its original core. Two successive SaaS organisations were then awarded contracts to replace EPIMS — both on price, both promising off-the-shelf systems, both failing: the first within 18 months, the second on strategic property requirements. OGP was under ministerial pressure to deliver.
Data
Twenty years of data, predating the standard
EPIMS had accumulated 20 years of government property data — building occupancy, staffing numbers, space utilisation, and cost information across the central government estate. The data existed but was locked into legacy systems, making it difficult to maintain and analyse. The data model was complex and required significant effort to work with, even for experienced teams.
The Government Property Data Standard — an externally published specification for how public sector organisations should structure and exchange property data — had been developed after EPIMS was built. EPIMS predated it and could not be retrofitted; any replacement had to be designed to the standard from the ground up. Meanwhile, inconsistent submission across 1,200 organisations meant the completeness and accuracy of the central register varied — directly affecting strategic decisions and the reliability of the State of the Estate Report.
Technology
No off-the-shelf product does this
EPIMS was built in 2005 and never fundamentally re-architected. By 2024 it was running on legacy .NET technology and on-premise virtual machines, creating security and sustainability risks — particularly around supportability and knowledge retention. It could not be cost-effectively aligned to the Government Property Data Standard or to modern GDS development standards.
Both failed procurements operated on the premise that an off-the-shelf property management system could be configured to meet OGP’s requirements. It could not. Standard property systems manage one organisation’s estate; a centralised strategic register for 1,200 public sector organisations is not a standard property management problem, and there is no off-the-shelf product that does it. The two attempts to prove otherwise cost government time and money.
The objectives
The overriding objective was time: a working system live before the end of the financial year. Beneath it, the goals operated at three levels: what individual users needed to do, what teams needed to change, and what the organisation needed to demonstrate.
01
Live before financial year end
The primary objective was time-driven: a working system live before the end of the financial year. Focus fell on delivering a minimum viable product within a tight window, not a fully-featured platform immediately.
02
Submit through the right channel
Property managers across 1,200 organisations needed to submit and maintain records through the channel that suited them — UI, API, or bulk import — not a single one-size-fits-all mechanism.
03
Empower employees with analytics
OGP’s data analysts needed structured, standards-aligned property data through their own BI tooling, reducing their dependency on CDS for analytical outputs.
04
An interface easier than EPIMS
Property managers needed a modern, accessible interface for data submission, and OGP’s service team needed a platform they could manage and support largely independently.
05
Auditable data for Parliament
Analysts and reporting teams needed to produce the State of the Estate Report from a clean, well-structured, auditable source — and OGP needed to show the PAC and ministers it had delivered.
06
Modern standards, room to grow
OGP needed a GDS-compliant platform aligned to the Government Property Data Standard for the first time — one it could extend incrementally without legacy constraints.
Our solution
Five months, twenty years in the making
CDS built InSite from contract award to production in five months. The window was achievable because twenty-plus years of domain knowledge substituted entirely for the discovery, functional specification and BA input that would normally precede a project of this scale.
Just as the challenge spanned people, process, data and technology, so did the solution.
The platform: InSite — a bespoke, GDS-compliant central property register for 1,200 organisations — replacing EPIMS, aligned to the Government Property Data Standard.
People
Making the case for bespoke
CDS worked closely with OGP’s Cabinet Office technology teams throughout — building and maintaining relationships with key technology partners and managing expectations across multiple stakeholder groups. We made the case to OGP and the Cabinet Office that rapid bespoke development was the only viable path following the two failed off-the-shelf solutions.
Our lead architect for EPIMS had been a consultant to OGP across the years and understood what was needed better than any other supplier. The delivery was deliberately scoped as a minimum viable product, with some EPIMS functionality intentionally omitted to prevent the new system from becoming overly complex again.
-
Close collaboration with Cabinet Office technologists throughout.
-
Active expectation management across OGP, departments and the PAC.
-
MVP scoping — deliberately leaving out legacy complexity.
Process
Domain knowledge instead of discovery
The InSite process was unique: there was no formal discovery phase — our domain knowledge substituted for it — and we had to work quickly, within a short deadline. The delivery strategy focused on MVP, reduced scope, managed expectations, and close collaboration with Cabinet Office technologists.
The data architecture for InSite — which would normally be a three-month exercise for a project of this scale — took days, because of twenty years of experience designing property database architectures and our direct involvement in developing the Government Property Data Standard itself.
-
No formal discovery — 20 years of domain knowledge stood in for it.
-
Three input channels designed and built: UI, API integration, bulk spreadsheet import.
-
All channels maintain consistency and integrity against the data standard.
Data
One register, standards-aligned throughout
InSite provides a central register of property data from 1,200 public sector organisations, with structured output for the State of the Estate Report to Parliament and data access for OGP’s internal analysts through external tooling — including MicroStrategy for reporting and analytics. The platform is aligned to the Government Property Data Standard data model throughout.
Data collected includes building occupancy, staffing numbers, space utilisation and cost information. OGP’s analysts, disposal teams, sustainability teams and senior executives each have distinct reporting needs — so InSite was designed to provide data access through external tooling, letting analysts work in their own BI environments rather than depending on CDS for every output.
-
Central register feeding the State of the Estate Report directly.
-
Aligned to the Government Property Data Standard data model throughout.
-
API-first access for OGP’s own BI environment (MicroStrategy).
Technology
Bespoke, GDS-compliant, built from the ground up
InSite is a bespoke application built to GDS development standards: a modern web front-end, API-first design for integration with external organisation systems, bulk import for large portfolio organisations, and a clean data model designed for external BI tooling. The stack includes modern front-end technologies, backend infrastructure for data storage and reporting, and Cloudflare Developer tooling used to improve development speed, with MicroStrategy providing reporting analytics.
The platform replaced the legacy .NET codebase and on-premise virtual machines of EPIMS with a modern application built from scratch — purpose-built for the unique requirement of a centralised strategic register for 1,200 organisations, rather than a standard property system configured to fit.
Cloudflare was deliberate architectural choice, not just a hosting decision. Deploying the Next.js front end on Cloudflare Pages removed the need for server provisioning, scaling configuration, and patching entirely. The pay-as-you-go pricing model means OGP only pays for the resources it uses, and the generous free tier on Workers makes the client application extremely cost-effective to run at scale.
Continuous integration and delivery is enabled through the next-on-pages package, allowing CDS to deploy updates rapidly as requirements evolve. The split architecture - with Cloudflare Pages at the edge for performance and Azure UK-South for data sovereignty - means users get fast page loads from Cloudflare's global network while sensitive government property data remains within UK-hosted infrastructure.
-
Modern web front-end · API-first · bulk import · clean BI-ready data model.
-
Cloudflare Developer tooling used to accelerate delivery.
-
Legacy .NET and on-premise VMs fully replaced.
The outcomes
01
Driving efficiency & productivity
Three data-input channels — UI, API and bulk import — make it significantly easier for 1,200 organisations to maintain their records, replacing a single submission mechanism that didn’t suit the diversity of organisations involved. OGP’s analysts can now access structured, standards-aligned data through their own BI tooling rather than depending on CDS for every output.
02
Empowering & enabling people
Property managers across 1,200 organisations have a modern, accessible interface for data submission that’s easier to use than EPIMS, and OGP’s service delivery team can manage and support the platform largely independently. The delivery of InSite gave OGP something tangible to take back to the PAC, demonstrating it had delivered on its modernisation commitments.
03
Visibility & control of risk
The estate is now managed on a platform, built with Cloudflare's Developer Platform and aligned to the Government Property Data Standard, providing the structured, auditable data the State of the Estate Report requires. A government pen test returned low-severity scores with no critical or serious vulnerabilities, and the public-facing Government Property Finder depends on InSite’s data for the disposal strategy.
.04
Accelerating modernisation
The central government property register is aligned to the Government Property Data Standard for the first time. InSite is built to GDS standards — API-first, modern front-end, clean data model — replacing a 20-year-old codebase that couldn’t be modernised. It was delivered in five months, demonstrating that modernisation at speed is achievable when domain knowledge is deep.
Why CDS
CDS did not win the InSite contract in a competitive procurement. After two competitors failed — both winning on price, both overestimating what off-the-shelf systems could do — OGP had no viable path forward except CDS. The persuasive argument was not price. It was the combination of domain knowledge, track record, and the demonstrable failure of every alternative. Our lead architect, had been working on government property data management since 1998 — and understood what was needed better than any other supplier.
01
Domain knowledge that nobody could match
Twenty years building and running the government property platform — and direct involvement in writing the Government Property Data Standard itself. No other supplier understood the problem as clearly.
02
The demonstrable failure of alternatives
Two competitors won on price, both overestimating what off-the-shelf systems could do, and both failed. After them, OGP had no viable path forward except CDS.
03
Delivery capability proven
A five-month delivery from contract award to production — meeting a ministerial deadline — is the proof that the combination of domain knowledge and delivery capability is real.
04
Trust built over two decades
The client’s own assessment is straightforward: they like working with CDS, they value the expertise, and they trust the relationship — built over twenty years.
Additional reading
Two optional sections for the technically curious and the delivery-minded. Skip them if you've got what you need!
Technical deep dive
Built to GDS application development standards, from the ground up.
System-to-system exchange for orgs with their own property systems
Used to improve development speed within the five-month window.
OGP's own BI tooling for reporting and analytics against InSite data.
The data model is aligned to it throughout — a first for the register.
~ 3 min read
Why bespoke was the only option
Two successive failed projects from SaaS vendors were based on the premise that a standard property management system could be configured to meet OGP’s requirements. Both failed for the same reason: standard property systems manage one organisation’s estate. InSite manages a centralised register of 1,200 organisations’ data for strategic government reporting. These are fundamentally different problems — configuring an off-the-shelf system to behave like a national strategic register is not a configuration exercise, it is a rebuild. CDS’s twenty years of domain knowledge made it the only supplier that understood this clearly enough to solve it.
Platform architecture
InSite is built on a split architecture, using modern web front-end technologies with a backend supporting data storage and reporting, and Cloudflare Developer tooling used to improve development speed. The data model is aligned to the Government Property Data Standard throughout.
The front end is a Next.js 15 application hosted on Cloudflare Pages, built to GOV.UK Frontend design system standards. It includes Leaflet-based interactive mapping with marker clustering, advanced list and map search views, geospatial polygon management using Geoman for boundary editing, and CRUD operations across 18-plus entity types. Ordnance Survey integration provides address lookup and raster tiles; tile server requests are proxied via a Cloudflare Worker and cached within Cloudflare.
The .NET backend remains in Azure UK-South for data sovereignty — keeping sensitive government property data and legacy integrations within a controlled Azure environment. The split architecture delivers edge performance for the user-facing application while maintaining the compliance and sovereignty requirements that a central government platform demands.
Three data-input channels serve the diversity of the 1,200 submitting organisations:
› User interface: For organisations managing data manually, typically smaller bodies with smaller portfolios.
› API integration: For organisations with their own property management systems, enabling direct system-to-system exchange.
› Bulk spreadsheet import: For large portfolio organisations where record-by-record UI entry isn’t practical.
All three channels maintain data consistency and integrity against the Government Property Data Standard data model.
Cloudflare architecture
The serverless architecture eliminates the overhead of managing traditional servers entirely: no provisioning, no patching, no scaling configuration. OGP pays only for what it uses. For a publicly funded body operating with a reducing annual budget, this cost model was a significant factor in the platform decision.
Cloudflare Workers serve two distinct functions in InSite: proxying and caching tile server requests to Ordnance Survey, reducing latency for geospatial views; and generating and destroying unique preview environments per code change at no additional cost. Preview environments give the development and test team isolated, production-equivalent environments for every code change — dramatically streamlining testing and review without infrastructure overhead.
Deployment is automated through Azure Pipelines, which manages the full CI/CD process for both frontend and backend. The pipeline includes automated accessibility and performance testing, ensuring every release meets government digital standards before it reaches users. The next-on-pages package simplifies deployment of the Next.js application to Cloudflare Pages, enabling CDS to deliver updates rapidly as OGP's requirements evolve — without the delays typical of traditional infrastructure-dependent deployment pipelines. The combination of free preview environments, automated pipelines, and zero server management overhead means the InSite development team spends time building features, not managing infrastructure.
Data architecture & reporting
InSite was designed for data access through external tooling — OGP’s analysts use MicroStrategy for reporting and analytics, accessing InSite’s data directly rather than depending on CDS-generated reports. The API-first design supports this pattern, providing clean, well-structured access for OGP’s own BI environment. Standard alignment means InSite’s data model is interoperable with the wider government property data ecosystem, including the Government Property Finder — the public-facing disposal site that depends on InSite’s data.
Integrations and development approach
InSite follows an OpenAPI-first development pattern: the .NET backend generates an OpenAPI specification that drives TypeScript type generation for the front end, providing end-to-end type safety from database to UI. This eliminates an entire class of integration bugs between front end and backend — a meaningful quality improvement for a system handling 18-plus entity types across complex property data structures.
Legacy authentication is handled by bridging NextAuth.js sessions with the existing ePIMS SOAP authentication service — connecting InSite's modern front-end authentication to established government identity infrastructure without requiring changes to the legacy backend.
Accessibility and security are built into the development process: axe-core automated accessibility testing is integrated throughout; CSRF protection, security headers middleware, and parameterised SQL queries are applied across the application.
Security
A government pen test of InSite returned low-severity scores, with no critical or serious vulnerabilities identified. Replacing legacy .NET and on-premise virtual machine infrastructure with a modern application removes the security and sustainability risks that had accumulated in EPIMS over 20 years.
Known limitations & future direction
InSite was deliberately scoped as an MVP. Some EPIMS functionality was intentionally omitted to prevent the new system inheriting the complexity that had made EPIMS difficult to manage. The current platform is built on top of some older elements, a known technical debt that OGP and CDS have identified for future resolution. The longer-term goal is a fully functioning platform where any part of the application can be worked on by any developer, therefore removing single points of failure and making the system fully accessible to a wider team.
Our ways of working
20 years of domain knowledge stood in for discovery and specification.
Deliberately focused, resisting the feature creep that bloated EPIMS.
A three-month data-architecture exercise compressed into days.
Across OGP, government departments and the PAC — clarity on MVP rationale.
Ongoing support, with strategic sessions on legacy and policy change.
Delivery approach
The InSite delivery was unlike any standard project model. The five-month deadline, the absence of a formal specification, and the depth of pre-existing domain knowledge required a deliberately pragmatic approach. The strategy was: MVP, reduced scope, managed expectations, and close collaboration with Cabinet Office technologists. Scope was managed actively throughout, keeping the system focused on its core purpose and resisting the feature additions that had caused EPIMS to become overly complex.
The data architecture that would normally take three months was completed in days. This was only possible because of twenty years of experience designing property database architectures and direct involvement in developing the Government Property Data Standard itself.
Stakeholder management
The Cabinet Office stakeholder environment is complex. Multiple teams within the Cabinet Office have oversight of technology decisions, and OGP’s technology leadership, property departments across government, and the PAC all had interests in the outcome. Managing expectations across these groups — particularly around the intentionally reduced scope of the MVP — was a critical part of delivery. There was initial feedback from departments about reduced functionality compared to EPIMS, which was managed through clear communication about the deliberate design rationale.
Ongoing service
Following go-live, CDS provides ongoing service and support through a managed service model. Strategic sessions are planned to focus on long-term goals — including addressing remaining legacy technology and the implications of government policy change on property data requirements.
Running a critical service that can't afford downtime?
We'd be glad to talk about what good looks like, whether you're at the start of replacing a legacy platform, looking to modernise and innovate, navigating a regulatory deadline, or trying to bring a non-technical team along for the ride.
Tell us a little about you and we'll come back within one working day.