Cloud transformation programmes often focus first on the destination: the target cloud platform, the migration tooling, the landing zone or the future operating model. In practice, the quality of the outcome is heavily influenced by how well the existing environment is understood before design decisions are made.
Current-state discovery is the discipline of establishing what exists today, how it is connected, who owns it, what depends on it and which risks or constraints could affect change. Without that baseline, architecture decisions are made with assumptions instead of evidence.
What current-state discovery should establish
A useful discovery exercise goes beyond an asset list. It should identify the relationship between infrastructure, applications, data, identity, networks, security controls, operational processes and business services.
For cloud programmes, this normally includes compute, databases, storage, DNS, network paths, firewalls, load balancers, identity and access, certificates, backups, monitoring, scheduled jobs, third-party services and external integrations. The important question is not simply what exists?, but what depends on what?
A virtual machine, for example, may look easy to migrate in isolation. Once its database connection, scheduled file transfers, service accounts, firewall rules, DNS dependencies and backup process are understood, the migration risk can look very different.
Dependency mapping is the real value
Most migration problems are not caused by a server being difficult to move. They are caused by an overlooked dependency.
Dependency mapping should therefore cover both technical and operational relationships. That includes upstream and downstream applications, data flows, integration endpoints, authentication methods, network routes, batch processes, support ownership and change windows.
It is also important to distinguish between documented dependencies and observed dependencies. Existing diagrams and runbooks are useful starting points, but they should be validated against the actual environment wherever possible.
Security and identity need to be discovered early
Identity is often treated as a later workstream, yet it is fundamental to cloud architecture. Discovery should establish how administrators authenticate, how service accounts are used, how privileged access is controlled, where secrets are stored and which applications depend on legacy authentication methods.
The same applies to security controls. Firewall rules, security groups, network segmentation, vulnerability management, logging, monitoring and audit retention all influence the target design. Moving a workload without understanding these controls can create either unnecessary exposure or unexpected service disruption.
For organisations reviewing cloud and security together, DNC’s Cyber Security and Ethical Hacking services can complement the architecture discovery process.
Operational discovery matters as much as infrastructure
A technically accurate migration can still fail operationally if the day-to-day service model is not understood.
Discovery should therefore cover backup and restore responsibilities, monitoring and alerting, incident handling, support contracts, patching, certificate renewal, capacity management and the teams or suppliers responsible for each area.
This is particularly important where several providers are involved. A cloud platform may be owned internally, the network managed by an MSP, a database supported by a specialist partner and an application maintained by a software vendor. Those ownership boundaries should be explicit before migration planning begins.
Use evidence, not assumptions
Good current-state discovery combines several evidence sources. These can include cloud inventories, configuration exports, network and firewall data, monitoring platforms, application documentation, support records and interviews with service owners.
Where possible, information should be cross-checked. A route shown on a network diagram may no longer exist. A server listed in a spreadsheet may already have been retired. A firewall rule may allow traffic that the application owner does not know about.
This is why reverse engineering an existing environment can be valuable. It creates an evidence-based view of the platform rather than relying entirely on historic documentation.
What should discovery produce?
The output should be useful for decision-making, not simply a collection of spreadsheets.
A strong discovery phase normally produces a current-state architecture, resource inventory, dependency view, ownership model, risk and issue register, identified technical debt and a list of assumptions requiring validation. These outputs then feed directly into the target architecture and migration plan.
For larger programmes, they can also provide the foundation for a High Level Design, Low Level Design and implementation runbooks. DNC provides Corporate Architecture and Technology Services for organisations that need this current-state-to-target-state structure.
Common mistakes
One common mistake is limiting discovery to infrastructure inventory. Another is starting target design before key dependencies are understood. It is also risky to assume that existing documentation is current, or that the people closest to an application know every network and integration dependency.
A further mistake is allowing discovery to continue indefinitely. The objective is not perfect knowledge. It is sufficient evidence to make controlled architecture and migration decisions, with remaining uncertainties recorded and managed.
What good looks like
Good current-state discovery gives the programme a shared, evidence-based understanding of the environment. Important dependencies are visible, ownership is clear, assumptions are documented and known risks are brought into the design process rather than discovered during migration.
That makes subsequent decisions around landing zones, connectivity, identity, resilience, security and migration sequencing more reliable.
Conclusion
Cloud transformation should not begin with the question, “Where do we move this workload?” It should begin with, “What exactly are we changing, and how does it operate today?”
Current-state discovery creates that foundation. It reduces avoidable surprises, improves target architecture decisions and allows migration planning to be based on evidence rather than assumption.
If your organisation needs help documenting an existing environment before migration or modernisation, see DNC’s Cloud Architecture and Engineering services or discuss your requirements with us.