There is a strong temptation, at the start of any transformation programme, to jump straight to the exciting part: the target architecture. The future-state diagram. The thing everyone is paying for. I understand the pull — but designing the To-Be before you genuinely understand the As-Is is how programmes end up building something elegant that doesn't fit the organisation it is supposed to serve.

Understanding the existing architectural landscape is the first real step towards defining the target one. Every design choice ahead of you is informed by what is already there. Skip that understanding, and you are not designing — you are guessing.

The As-Is is a directive, not a history lesson

People sometimes treat the current-state assessment as box-ticking — document what exists, file it, move on. That misses the point. A proper As-Is gives you a high-level directive: it tells you exactly what you are transitioning from, which means it tells you what the programme actually has to do to get to the future state. The gap between an honest As-Is and a well-defined To-Be is the scope of the work. You cannot size the journey until you know the start line.

What you are actually looking for

A good current-state assessment is not just an inventory of systems. You are looking for three things in particular: the open issues and functional gaps where today's tools fall short, the quality concerns that are quietly costing the business, and the functional inconsistencies — the places where two departments do the same thing in two different ways because their systems grew up separately.

The questions that get you there are blunt ones. What are the current pain points and known issues? Where is the organisation inconsistent in how it does its work? What quality problems does everyone already know about but nobody owns? The answers tell you where a new platform has to earn its place.

Follow the data

Architecture diagrams are the visible part of the As-Is. The data underneath them is the part that decides whether the transformation is hard or straightforward. For every significant data source you need to know what it is, how it is used, and how good it is — duplicates, referential integrity, overall cleanliness. You also need to decide, early, which system is the system of record for each domain and which systems are merely references to it. An organisation with three CRMs and no agreed source of truth for customer data does not have a technology problem first — it has a master-data problem, and the technology programme will inherit it whether you plan for it or not.

Document it so it can be argued with

The output of all this is a set of architecture diagrams and supporting documentation — one clear, high-level picture per business unit of the systems in place and how they talk to each other. The value of writing it down is that it can then be checked, challenged and corrected by the people who live in those systems every day. A current-state model that only exists in the architect's head cannot be argued with, which means it cannot be trusted.

Design for the organisation that is coming, not just the one in front of you

One last thing the As-Is has to capture: change that hasn't happened yet. Organisations are not static. There is usually an ERP replacement on the horizon, a new regulatory constraint, an expansion into another region, or a third-party AI tool someone has already bought. If you design the To-Be purely against today's reality, you will be re-architecting within eighteen months. The current-state assessment is the right moment to ask what is coming, and to make sure the target architecture can absorb it.

Do this properly and the To-Be almost designs itself — it becomes the shortest credible path from a start line you actually understand to a future state the organisation can actually use. Skip it, and the most beautiful target architecture in the world is still just a guess.

This post is adapted from the chapter on understanding the existing architectural landscape in my book, the Microsoft Power Platform Solutions Architect's Handbook (Packt, 2nd edition). If your programme is heading into design without a current-state model everyone agrees on, that is usually worth fixing first.