Saving a Modernization Effort by Identifying the Missing Piece
A large enterprise modernization effort stalled five months in because no one owned the data architecture.
The Situation
A global enterprise physical security company with approximately 87,000 employees was modernizing a core application that had evolved over roughly twenty years, driven by a shift away from an aging application framework, a move to web-based interfaces, and rising security requirements. A large consulting firm was engaged to execute the effort and was expected to deliver the first version within the year. Five months in, progress was already stalling.
What We Found
The modernization strategy had built specialized teams around visible technical concerns like infrastructure, authentication, and deployment pipelines, on the assumption that the architecture would emerge naturally if each team delivered its part. One critical area had no dedicated team, no documented plan, and no clear ownership: data. A simple question about where authentication data would live had no clear answer, and we discovered new databases and infrastructure were already being built without a broader data strategy. When we asked for a complete architectural picture, the best answer we received was a hand-drawn sketch of the data layer. There was no shared plan for data ownership, domains, service boundaries, or migration strategy.
What Changed
We presented the architectural gaps to client leadership using existing diagrams, implementation decisions, and the unresolved questions that kept surfacing. Once the risk became visible, leadership asked us to take responsibility for defining the data architecture. We assembled a focused working group of about six people and ran an intensive working session to answer foundational questions: what domains exist, which services own which data, where boundaries should sit, and how the legacy system could evolve without a full replacement. Significant disagreements about cross-domain relationships, scalability, and security were surfaced and resolved directly instead of staying hidden.
What Followed
The resulting architecture was formally adopted, and implementation began immediately, first within a single domain and then replicated across additional domains and services. The client continued using the approach internally and was able to modernize iteratively rather than attempt a high-risk, all-at-once migration. The greatest risk on this project was never technical failure. It was the absence of a coherent data architecture, which put every team's ability to coordinate and deliver at risk. Once shared architectural alignment existed, progress became possible again.
Share this case study
Facing a similar situation?
Start with a conversation. We help organizations understand what is actually happening before committing to a path.
Start a Conversation