Two kinds of warehouse, and why it decides your options

Before anything else, work out which kind of platform you have been given. In my experience they come in two broad shapes, and the shape determines what is available to you far more reliably than size, source platform or target design.

The architected platform was designed. It has an intentional layering — bronze, silver and gold, or staging, integration and presentation, or whatever vocabulary its era used — with deliberate models, documented lineage and a team that understands it. It was built by architects and it shows.

The organic platform accumulated. It was built by and for lines of business, extended whenever someone needed something, and its structure is a record of a decade of individual requests rather than a design. Documentation is thin or wrong. The people who know why a particular table exists have mostly left.

The intuitive expectation is that the architected platform is the easier migration. It is not. The two present almost exactly inverted challenges.

The organic platform: decomposable, but undocumented

The good news is structural. An organically grown estate usually breaks along line-of-business lines, because that is how it was built — one department’s data, one department’s loading jobs, one department’s reports, with fewer cross-domain dependencies than anyone expects. Domains can genuinely be lifted, moved and cut over one at a time. Waves are not just possible here; they are the natural shape, and each wave is a small enough blast radius that the business will accept it.

The bad news is that you do not know what anything is. There is no model to migrate against, no lineage to check your reconciliation, and no owner who can tell you whether a transformation is business logic or a workaround for a bug in a system that was retired in 2014. Every domain requires archaeology before it requires engineering.

What this means practically:

• Front-load discovery, and staff it with people who can read code. The dependency map has to be recovered from the systems — query logs, scheduler definitions, BI metadata, database dependency views — because nobody can tell you.
• Expect reconciliation to be the hard part, not movement. Where there is no specification, “correct” means “the same numbers as before”, which makes business-owner time your binding constraint.
• Use the domain boundaries you are given. Resist the urge to rationalise the estate into a cleaner shape as part of the move; that is a second project wearing the first one’s budget.
• The retirement opportunity is enormous. Organic estates carry the most dead weight of any kind, precisely because nothing was ever designed out. The usage-evidence exercise pays for itself several times over here.

The architected platform: understood, but entangled

Here the position reverses. You have models, lineage and people who understand the system. What you also have is a dependency structure that is genuinely hostile to incremental migration.

The layering that makes a well-architected platform good to operate is exactly what makes it hard to decompose. Silver is built from bronze across domain boundaries. Gold aggregates across silver. Conformed dimensions are shared by everything by design — that is the whole point of them. There is no clean vertical slice through the platform that takes one business domain and leaves the rest untouched, because the architecture was specifically built to prevent domains from being isolated from one another.

The consequence is uncomfortable: a well-architected medallion platform tends to force either a big-bang cutover or a rebuild. Attempts to migrate it in domain waves usually fail on the discovery that wave one’s gold layer depends on silver tables that wave three owns, and you have created a cross-platform dependency in the most heavily-used part of the estate.

That is the general position. Making an architected platform decomposable is how I have got round it.

The label is not evidence

Be careful of what you are told you have. “EDW” is frequently a claim about intent rather than a description of what was built.

I have seen a number of platforms presented as enterprise data warehouses that were nothing of the kind. What they actually were was hosting environments for line-of-business sandpits — independent analytical areas, spun up for a specific team and a specific question, never integrated with anything, and never intended to last. Then they outlived their purpose. Someone built a process on one. A report went into a monthly pack. Over a few years a temporary analytical area quietly became load-bearing for a business process, with no design, no documentation and no owner who thinks of it as production.

This is the far end of the organic archetype, and it is materially worse than the ordinary version, because there is not even an accidental structure to work with — just a collection of unrelated islands sharing infrastructure and a name.

Establish which archetype you actually have from the evidence: the dependency graph, the scheduler, the query logs, and how much of the estate genuinely shares conformed structures. Do not take it from the architecture diagram, which describes the platform someone intended to build.

What has quietly become operational

Related, and more dangerous, because it happens to good platforms too.

Analytical platforms accrete operational dependencies. Something gets built as a reporting asset, it turns out to be the best available version of some entity, and over time systems start depending on it for things that are not reporting at all.

The clearest case I have seen involved a conformed cross-line-of-business customer view — exactly the asset a good warehouse is supposed to produce — that became so much better than anything the operational estate held that enterprise billing came to be driven from it. At that point it was carrying billions of dollars of revenue and had become effectively untouchable. Field note: The EDW that ended up driving billing

The distinction matters because it changes the risk category completely. A reporting outage is an irritation and a difficult morning. A billing outage is an existential event with contractual and regulatory consequences, and it will be governed accordingly — different approvals, different testing standards, different tolerance for the cutover you had planned.

So inventory this explicitly and early. For each significant data asset, ask not what it was built for but what now depends on it, and what happens if it is wrong or unavailable for a day. Anything that turns out to be feeding billing, pricing, payments, regulatory submission, customer communication or an operational system is not a reporting migration problem. Isolate it, escalate it, and treat it as its own piece of work with its own governance — or accept early that it constrains the shape of the whole programme.