SAP Landscape Assessment and Discovery

SAP Landscape Assessment and Discovery is the process of fully understanding an organisation's existing SAP environment before trying to migrate it to AWS. Think of it as the 'know before you go' phase. Without it, you might promise a two-month migration and discover during week one that you have a twenty-year-old database that nobody knows how to move.

The 'landscape' is the entire collection of SAP systems a company runs. A typical large company might have dozens of them: one for financials (SAP S/4HANA), one for payroll (SAP ERP), one for business intelligence (SAP BW), plus a handful of 'sandbox' systems where developers experiment, 'development' systems where new features are built, 'quality assurance' systems where changes are tested, and 'production' systems where the live business runs. Each of these systems runs on a server (a powerful computer) with its own operating system (OS), usually Linux or Windows, and its own database (where all the data lives), frequently SAP HANA or Oracle.

An 'assessment' means inspecting each component for health, age, and compatibility. Health means: is the database running slowly? Are its disks nearly full? Age means: is the operating system version ten years old and no longer supported by its vendor? Compatibility means: will this version of SAP HANA run correctly on the AWS instance type you plan to use? You cannot move a system with a fatally ill database onto a new platform and expect it to heal.

'Discovery' goes a step further and uncovers dependencies. A dependency is when one system relies on another to function. For example, a company's SAP Portal might pull data from an SAP BW system, which in turn gets its raw data from an SAP ERP system. If you move only the ERP system to AWS but leave the Portal and BW on your old on-premise (meaning: running in the company's own data centre) servers, the Portal will have to talk across a network connection that might be slow or unreliable. Worse, you might not even know that dependency exists until the portal breaks after the migration.

The AWS PAS-C01 exam tests this heavily. You will be given a scenario describing a company with multiple SAP systems and asked to identify what needs to be discovered, what assessments must be performed, and what dependencies must be mapped before migration starts. The exam also tests specific AWS tools that help with this. For example, AWS Migration Evaluator (formerly known as TSO Logic) is a tool that scans your on-premise servers and tells you what kind of AWS instance you should use. AWS Application Discovery Service discovers your running processes and network connections, revealing dependencies. You can also use SAP-specific tools like SAP Early Watch Alert (EWA) reports, which give you a health check on each SAP system.

Why does this exist? In the old days, companies migrated by copying everything blindly and hoping it worked, often leading to outages, lost data, and blown budgets. Now, the industry standard is to do a thorough assessment first, so you know exactly what you are dealing with. This is like a builder inspecting a house before agreeing to move it to a new foundation — any cracks, rot, or weak spots must be identified before the giant lift.

What does it replace? It replaces guesswork and 'big bang' migrations where everything moved at once. Historically, IT teams would shut down all systems, copy them over, reboot, and pray. Assessment and Discovery turns that into a structured, data-driven project where you know the risks, plan the work, and avoid the prayer.

A medium-sized manufacturing company, Papermill Co., runs four SAP systems: a production SAP S/4HANA system for its financials and inventory, an SAP BW system for reporting, an SAP Solution Manager for monitoring, and an SAP Portal for external suppliers. They are planning to move the entire landscape to AWS. As the IT analyst responsible for the assessment, here is what you do step by step.

First, you collect all system information. You log into each server and run commands to find the operating system version, the database version, the CPU and memory sizes, and the disk usage. You also run SAP-specific reports: the SAP Early Watch Alert report for each system, which gives you a health score and warns about issues like long-running database queries or low disk space. You gather the results into a spreadsheet that lists every system, its role (Production, QA, Development), its hardware specs, and its health status.

Second, you map dependencies. You ask the business teams: which reports rely on data from which system? Does the Portal call back to the BW system every time a supplier logs in? You also use a network monitoring tool, like AWS Application Discovery Service, that you install on the servers for two weeks. It watches every network connection and builds a map of who talks to whom. You discover that the BW system receives data from an old file server that was not even on the original list. That file server must be included in the migration plan, or the BW system will have no data to report.

Third, you assess readiness. You check if the OS is on the AWS-supported list for SAP. You find that the BW system runs an older version of SUSE Linux that AWS no longer supports. You now know you must either upgrade the OS before migrating or use a special migration method that handles OS changes. You also check the database sizes. The S/4HANA database is 5 TB. You need to make sure AWS has instance types big enough to hold it with room to grow.

Fourth, you plan the migration strategy. The assessment reveals that the Production S/4HANA system cannot have more than an hour of downtime. That rules out a full data copy followed by a long cutover. You decide to use AWS's SAP HANA System Replication, which keeps a copy in AWS in sync with the on-premise system, allowing a failover that takes only minutes. This decision is only possible because the assessment identified the low-downtime requirement.

Finally, you create a report summarising everything: which systems are ready to migrate now, which need upgrades first, all dependencies mapped, and the recommended migration approach for each. That report becomes the blueprint for the actual migration project. - Tools you would use in this scenario:

- AWS Migration Evaluator (for right-sizing server recommendations) - AWS Application Discovery Service (for dependency mapping) - SAP Early Watch Alert (for health checks) - Manual OS and database queries (for version checks)