Quick Answer
- BASIS interviews test 8 core areas: architecture, installation, client administration, security/authorizations, transport management, monitoring, backup/recovery, and S/4HANA migration.
- Transport Management System (STMS) and client administration questions appear in nearly every BASIS interview — they're the most distinctly "BASIS" (non-generic-IT) topics.
- S/4HANA migration and RISE with SAP questions are now standard in 2026 interviews, reflecting the industry-wide migration wave ahead of SAP's ECC maintenance deadlines.
- Interviewers consistently favor candidates who've actually used the monitoring transactions (SM50, ST03N, ST04) over those who only know the transaction codes by name.
- This guide is aligned with the SAP C_TADM_23 certification syllabus, so it doubles as exam prep.
Core Concepts
BASIS Fundamentals & Architecture
15 Questions
Every BASIS interview starts here — system architecture, the three-tier model, and how SAP's technical layer actually fits together. Get these wrong and nothing else matters.
SAP BASIS stands for Business Application Software Integrated Solution — SAP's technical administration layer. BASIS is responsible for installing, configuring, monitoring, securing, and maintaining the entire SAP system landscape: application servers, databases, transports, users, and performance.
The Presentation layer (SAP GUI/Fiori, where users interact), the Application layer (application servers running the actual business logic and work processes), and the Database layer (where all business data physically lives). BASIS administrators work primarily across the application and database layers.
An instance is a group of resources (work processes, buffers, and an instance profile) sharing a common set of memory and process resources, identified by a unique instance number. A single SAP system can have multiple instances (application servers) spread across different physical or virtual hosts.
A work process is the general term for any of the several process types an instance runs (dialog, background, update, spool, enqueue). A dialog process specifically handles interactive user requests — screen transactions triggered directly by a logged-in user.
Dialog (D) for interactive user requests, Background (BGD) for scheduled batch jobs, Update (UPD/UPD2) for asynchronous database updates, Spool (SP) for print/output formatting, and Enqueue (ENQ) for managing SAP's internal lock table.
NetWeaver is SAP's integration and application platform underlying most SAP products — providing the technical foundation (application server ABAP and/or Java, connectivity, and integration services) that business applications like ECC and S/4HANA run on top of.
ECC can run on multiple database vendors (Oracle, DB2, SQL Server, etc.), while S/4HANA runs exclusively on the SAP HANA in-memory database. This changes BASIS responsibilities significantly — HANA-specific backup/recovery, HANA administration tools (HANA Cockpit/Studio), and different sizing and memory management considerations.
A logon group is a set of application server instances grouped together so SAP's load balancing (via the message server) can distribute user logons evenly across them, rather than everyone connecting to one specific server — improving performance and resilience for larger landscapes.
The message server is a central component that handles communication between application servers in a distributed SAP system, and is also used for logon load balancing — it knows the load on each application server and directs new user sessions to the least busy one within a logon group.
The enqueue server manages SAP's internal lock table, ensuring that when one user is editing a record, no other user can make conflicting changes simultaneously. It's critical because if the enqueue server fails, data integrity across the whole system landscape is at risk — which is why it's a key focus of high-availability design.
An ABAP stack runs applications written in ABAP (most classic SAP business applications — FI, MM, SD). A Java stack runs Java-based applications (like older Enterprise Portal or PI/PO components). Some SAP systems are 'dual-stack', running both, though SAP has moved most modern development away from dual-stack architectures.
Solution Manager is SAP's central platform for managing the technical and business processes across an entire SAP landscape — it's used for centralized monitoring, change/transport management, system landscape documentation, and coordinating upgrades and support incidents across all connected systems.
Historically, the central instance hosted the special central services (message server, enqueue server) alongside regular application server functions. A dialog instance (or additional application server) runs only regular work processes without those central services, purely adding processing capacity.
High availability means designing the system landscape so a single component failure doesn't bring down the whole system — through clustering, failover, and redundancy. The enqueue and message server were historically single points of failure (only one instance holds the lock table at a time), which is why SAP developed the Enqueue Replication Server (ERS) specifically to make that component resilient.
RISE with SAP is SAP's cloud-bundled offering of S/4HANA Cloud plus infrastructure, migration tools, and managed services. For BASIS professionals, it shifts significant infrastructure and some operational administration to SAP/hyperscaler-managed environments, but system configuration, transport management, and application-layer administration skills remain essential — the role shifts rather than disappears.
Standing Up a System
Installation & System Setup
15 Questions
The technical foundation of BASIS work — how a system actually gets installed, sized, and configured before anyone can log in and use it.
Estimating the expected data volume, number of concurrent users, and workload type to determine appropriate CPU, memory, and storage requirements — typically using SAP's Quick Sizer tool or vendor-specific sizing guidance — before selecting hardware/cloud infrastructure and installing.
The kernel is the set of OS-level executable programs that make up the core runtime of an SAP instance — independent of the ABAP/application layer. Kernel version compatibility matters because SAP requires specific minimum kernel patch levels for certain application features, security fixes, and support pack compatibility.
Setting up the initial clients, applying the latest support packages, configuring the transport management system (STMS), setting profile parameters, configuring printers/spool, setting up background job scheduling, and performing initial security hardening (default password changes, SAP_ALL restriction).
The default profile (DEFAULT.PFL) contains parameters common to all instances of a system. The instance profile contains parameters specific to one particular instance (like the number of work processes of each type on that server) — instance-specific settings override the default profile's values.
SAP systems follow a standardized directory layout (e.g. /usr/sap/<SID>, work directories, transport directories, exe directories) so tools, scripts, and support processes can predictably find logs, executables, and configuration files — deviating from this structure without good reason complicates troubleshooting and SAP support.
SAP requires a valid digital license key (via transaction SLICENSE) tied to the system's hardware key, without which the system runs in a restricted temporary license mode with an expiry. Administrators request the permanent license from SAP (via the SAP Support Portal) using the system's hardware key and apply it through SLICENSE.
Via
sapcontrol (command-line, used in scripts and by SAP MMC/monitoring tools) or the SAP Management Console GUI, which properly sequences stopping/starting the database, then the SAP application instances, respecting dependencies rather than just killing processes.An application server (dialog instance) is an additional instance added to a system purely for extra processing capacity, sharing the same database. Adding one involves running SWPM (Software Provisioning Manager) on the new host, pointing it at the existing central system, and configuring the new instance's profile.
SWPM is SAP's standard tool for installing, uninstalling, and performing certain system copy/system rename operations for SAP systems — replacing older separate tools, it's guided (menu-driven) and handles most installation-time provisioning tasks.
A homogeneous system copy keeps the same operating system and database platform as the source. A heterogeneous system copy migrates to a different OS and/or database platform (e.g. migrating from an AnyDB system to a HANA-based system), requiring export/import via database-independent formats.
Unicode conversion migrates a non-Unicode SAP system to Unicode encoding, required to support multiple languages/character sets simultaneously and mandatory before certain upgrades (like moving to S/4HANA, which requires Unicode). It's a significant technical project involving export, character set conversion, and reimport.
Maintenance Planner (SAP's cloud-based planning tool, replacing the old Maintenance Optimizer) calculates the required support packages, add-ons, and dependencies for a target system state, and generates the stack file used to drive SUM (Software Update Manager) during installs and upgrades.
SLD is a central repository storing information about the software components and technical systems in a landscape — used by tools like Solution Manager and PI/PO for landscape-aware functionality, ensuring different tools have a consistent, accurate picture of what systems exist and their versions.
For S/4HANA, the database choice is fixed (SAP HANA), so the main OS decisions are around SUSE/Red Hat Linux distribution and version compatibility with the target HANA and kernel versions, cloud vs. on-premise infrastructure choice, and whether high-availability clustering (like Pacemaker on Linux) is required from day one.
An installation creates a completely new, empty SAP system. A system copy creates a new system by copying an existing one's data/configuration (used e.g. to build a QA system from Production). A system refresh specifically overwrites an existing system's data with a fresh copy from another system (commonly refreshing QA or Dev with recent Production data), reusing the target system's existing technical setup.
SCC4, SCC1, System Copy
Client Administration
15 Questions
Clients are how one SAP system technically separates multiple business/testing environments internally — a distinctly BASIS-flavored topic that comes up in nearly every interview.
A client (identified by a 3-digit number, e.g. 100, 200, 800) is a self-contained business/organizational unit within one SAP system — with its own master data, transactional data, and customizing, isolated from other clients in the same system. It's the mechanism that lets one installed system logically host multiple separate environments (e.g. Golden config client, testing client).
SCC4 is used to create and maintain client definitions — setting the client's role (Production, Test, Customizing, Demo), the change/transport settings for that client (whether customizing changes are automatically recorded), and other client-level protection settings.
A client copy duplicates data from one client to another (SCCL for local copy within the same system, SCC9 for remote copy between systems). Common profiles include SAP_ALL (everything, including transaction data), SAP_CUST (customizing only), and SAP_UCSV (customizing and user master, no transaction data).
A local client copy (SCCL) copies between two clients within the same physical SAP system. A remote client copy (SCC9, via RFC) copies between clients in two different SAP systems — used, for example, to refresh a QA system's client from Production.
Client export (SCC8) generates transport-request-based files of a client's data that can be manually transferred and imported (STMS import) into a target system. It's used when there's no direct RFC connectivity between source and target systems, or when the copy needs to move across landscapes that aren't directly linked.
SCC1 copies specific transport requests' changes from one client to another within the same system — useful for propagating a specific customizing change into another client without doing a full client copy.
A system refresh overwrites a lower environment (like QA) with a recent copy of Production data, typically via a full system copy or client copy, followed by post-refresh steps: resetting RFC destinations, re-scheduling background jobs, anonymizing sensitive data if required, and reapplying environment-specific configuration that shouldn't have come from Production.
This is technically a system-level (not client-level) distinction — a homogeneous copy keeps the same OS/DB platform, while heterogeneous changes it — but it directly affects client administration because heterogeneous copies require export/import via database-independent tools rather than a direct database-level copy.
Client deletion (SCC5) permanently removes all data belonging to a client from the system. It must be done carefully because it's irreversible without a backup, can take significant time/resources on large clients, and accidentally selecting the wrong client number has caused real production incidents in poorly-controlled environments.
Client 000 is SAP's reference client containing SAP's original delivered configuration, used as the source for creating new customizing clients and for certain administrative tasks — it should never be used for actual business transactions. Client 001 is typically an early copy of 000 provided as a starting point for building the actual working client.
Set the client's change/transport setting in SCC4 to 'No changes allowed' or 'Changes without automatic recording' for direct customizing entry, ensuring configuration changes only enter Production via properly tested and approved transports rather than direct manual entry — a core change-control principle.
Client-specific customizing only applies to the client it was made in (most configuration). Cross-client customizing applies system-wide regardless of client (like certain currency or unit-of-measure settings) — administrators need to understand this distinction because cross-client changes in a shared development system can unexpectedly affect other teams' clients.
RFC destinations pointing to Production systems get carried over and must be redirected to QA equivalents (or disabled) to prevent accidental cross-system actions; background jobs scheduled in the copied data need to be reviewed and often disabled/rescheduled; and email/output configuration must be adjusted so QA testing doesn't send real communications to real customers.
A client copy typically moves a broad, predefined bundle of data based on a copy profile (via SCCL/SCC9). A client transport (via transport requests and STMS) moves specific, individually-selected changes — much more granular and controlled, which is why Production changes flow via transports rather than repeated client copies.
Because a mistake — copying into the wrong client, deleting the wrong client, or misconfiguring change settings — can affect an entire business unit's data or expose Production to untested changes, with limited or no easy undo. It's an area where BASIS teams typically enforce strict approval and verification steps before executing.
SU01, PFCG, Roles
User & Authorization Management
15 Questions
Access control is a shared responsibility between BASIS and Security teams, but every BASIS interview expects solid working knowledge of user administration and the authorization concept.
SU01 maintains a single user master record (creating, changing, or displaying one user at a time). SU10 is the mass user maintenance transaction, letting you apply the same change (like assigning a role) to many selected users in a single action.A role is a container of authorizations assigned to users, built via PFCG. A single role contains a specific, focused set of authorizations for one function. A composite role bundles multiple single roles together for convenience of assignment, but has no authorization data of its own — it's purely a grouping mechanism.
PFCG is the tool used to build and maintain roles — you assign transactions/menu items to a role, and PFCG automatically proposes the relevant authorization objects and default values, which the administrator then reviews, adjusts, and generates into an actual authorization profile assigned to users.
An authorization object is a template defining up to 10 authorization fields that must all be satisfied together for access to be granted (e.g. company code + activity for a financial transaction). It's the underlying technical building block that PFCG roles ultimately assign values to.
A derived role inherits the menu/transaction structure and most authorization values from a parent role, but allows organizational-level values (like company code or plant) to differ — commonly used for the same job function across different plants or regions. A composite role simply bundles unrelated single roles together with no inheritance relationship.
SAP_ALL is a predefined profile granting essentially unrestricted access to everything in the system. It's a major security and audit risk because it violates the principle of least privilege, and its use (especially in Production) is a standard focus of security audits and SOX/compliance reviews — it should be tightly restricted to true emergency/firefighter access.
SoD ensures no single user has access to perform two conflicting steps of a sensitive process alone (e.g. creating a vendor AND approving payments to that vendor), reducing fraud risk. Authorization design must proactively check role combinations against SoD rulesets (often using tools like SAP GRC Access Control) rather than just granting broad access.
SM20 lets administrators review a log of security-relevant events — failed logon attempts, authorization check failures, sensitive transaction usage, user master changes — used for security monitoring, incident investigation, and audit/compliance evidence.
Transaction-level authorization simply controls whether a user can even call a given transaction code (via authorization object S_TCODE). Field/value-level authorization goes further, controlling which specific data the user can see or act on within that transaction (e.g. which company codes, which document types) — most real-world security design requires both layers working together.
A user group (assigned in SU01) is an organizational grouping of users that can be used to restrict which administrators are allowed to maintain which users — an administrator can be authorized to only manage users within specific user groups, useful for delegating user administration by business area without granting full user-admin rights.
Run transaction SU53 immediately after the failed action to see the specific authorization object and values that failed the check, or use the authorization trace (ST01/STAUTHTRACE) for more complex cases — then compare what the user's assigned roles actually grant against what was required, and adjust the role rather than granting broad emergency access as a permanent fix.
Dialog — normal interactive users. System — background/RFC users, no interactive logon, no password expiry enforced the same way. Communication — for external system RFC calls, no dialog logon. Service — shared logon for anonymous access (e.g. some web scenarios), tightly restricted. Reference — never logs on directly; used purely to pass additional authorizations to other users via reference user assignment.
Password policy (minimum length, complexity, expiry, history) is configured via system profile parameters (like
login/min_password_lng) and enforces baseline account security — a standard item BASIS/Security teams review together during audits, especially for systems handling financial or personal data.A firefighter process grants temporary, tightly logged elevated access (sometimes via SAP GRC's Emergency Access Management, or manually via time-limited SAP_ALL-type role assignment) for urgent production issue resolution, with all actions during that window subject to review. BASIS is often responsible for provisioning and de-provisioning this access correctly and on schedule.
BASIS typically handles the technical mechanics — user creation/locking, system-level authorization troubleshooting, role transport between systems — while a dedicated Security/GRC team (or function) usually owns role design, SoD rule sets, and access request approval workflows. In smaller organizations, BASIS often covers both.
STMS, Change Control
Transport Management System
15 Questions
How changes move safely from Development to Production without breaking anything along the way — one of the most heavily tested topics in any BASIS interview.
TMS is SAP's mechanism for moving configuration and development changes between systems in a controlled, sequenced, auditable way (STMS transaction). It's central to BASIS because uncontrolled or mismanaged transports are one of the most common causes of production outages.
A transport domain is the group of systems (Dev, QA, Prod) managed together under one TMS configuration, with one system designated the domain controller. A transport route defines the specific path a transport takes between systems (e.g. Dev → QA → Prod) and whether it's a consolidation or delivery route.
A transport layer is a logical grouping assigned to development objects/packages that determines which consolidation route they follow. A transport route is the actual defined path between specific systems that transports of a given layer travel along.
A transport request is a container tracking a set of related changes, consisting of a request header (owner, description, target system) and one or more tasks (where individual developers actually record their specific object changes) beneath it.
A workbench request carries cross-client development objects (programs, CDS views, Data Dictionary changes) and must be explicitly transported to move between clients. A customizing request carries client-specific configuration changes and is tied to the specific client it was created in.
SE01 or SE09/SE10 (Transport Organizer) to create and release transport requests/tasks, and STMS (specifically the import queue, STMS_IMPORT) to import released transports into the target system.Releasing generates the actual data files (the .dat file with data and .cofile with control information) for that transport in the transport directory, locks the request from further changes, and adds it to the import queue of the next system(s) on its transport route.
The import queue (viewed and managed in STMS) shows released transports waiting to be imported into a given system, in the order they should typically be imported. Administrators can reorder (with caution), add, or remove transports from the queue, and trigger the actual import.
A transport of copies moves a snapshot of an object's current state without requiring the full standard sequential route or without needing the original development request — useful for urgent one-off fixes. A standard transport follows the normal request/task/release/import flow along the defined transport route.
Common causes: missing predecessor objects/transports not yet imported, version conflicts (object changed independently in target), or authorization issues. Troubleshooting starts with the import log (in STMS) to identify the specific return code and object, then addressing root cause — often re-importing predecessor transports first.
A 3-system landscape (Dev → QA/Test → Production) is SAP's most common recommended setup, giving one dedicated testing tier before Production. Some organizations use additional tiers (like a separate Sandbox or pre-Production tier) for more complex change control needs, though this increases transport route complexity.
Import All imports every transport currently in a system's queue in one action, in the correct sequence — convenient for routine QA/Prod refresh cycles. It's risky when the queue contains transports that haven't actually been tested/approved yet, since it doesn't discriminate — good change control practice usually means selectively importing only approved transports, not blindly running Import All in Production.
A transport strategy defines rules for how and when changes move between systems — freeze periods before go-live, who can release/import transports, sequencing rules for dependent transports, and rollback procedures. Without one, teams risk conflicting or out-of-sequence changes causing inconsistent system states.
This creates a transport collision risk — whichever transport is imported last effectively overwrites the other's changes to that object unless carefully coordinated, which is why version management and communication between developers working on overlapping objects matters, and why some organizations use tools like the SAP Change and Transport System's own object locking to catch this.
Follow the organization's emergency change process — typically requiring expedited approval, careful review of what the transport actually contains (to avoid accidentally including unrelated unfinished work bundled into the same request), and immediate post-import verification, followed by proper documentation after the fact even though the process was expedited.
SM50, ST03, CCMS
System Monitoring & Performance
15 Questions
Keeping a live SAP system healthy day to day — the monitoring transactions and performance tuning concepts that come up constantly in operational BASIS interviews.
CCMS (Computing Center Management System) is SAP's built-in framework for centralized system monitoring — tracking performance metrics, alerts, and system health across the landscape, historically accessed via RZ20, now largely superseded in day-to-day use by Solution Manager's monitoring capabilities but still foundational.
SM50 shows the work process overview for the current application server instance you're logged into. SM66 shows a global work process overview across all application server instances in the system, useful for spotting issues that might not be visible from a single server's view.ST22 (ABAP Dump Analysis) shows runtime errors (short dumps) that occurred in the system — a critical first stop when investigating a reported error, since it captures the technical details (program, error type, variable values at time of failure) needed to diagnose the root cause.
SM21 (System Log) shows a broader log of system-level events and errors beyond just ABAP dumps — including database issues, operating system-level problems, security events, and more. ST22 is specifically focused on ABAP program runtime errors (short dumps).
ST03N (Workload Monitor) provides statistical analysis of system performance and workload over time — response times by transaction, load by user, and trends — used for capacity planning and identifying which transactions or time periods are consuming the most system resources.
ST04 provides database performance monitoring — showing database-level statistics like buffer hit ratios, table/index sizes, and expensive SQL statements, letting administrators diagnose whether performance issues originate at the database layer specifically.
STAD (Statistical Records) shows detailed, individual transaction-level statistics for specific execution instances (a single user's single transaction call and its exact response time breakdown), whereas ST03N shows aggregated, summarized statistics across many executions — STAD is for drilling into one specific slow instance, ST03N is for spotting broader trends.
SM36 is used to schedule new background jobs (defining steps, start conditions, and variants). SM37 is used to monitor and manage already-scheduled or completed background jobs — checking status, viewing job logs, and cancelling or rescheduling jobs as needed.SAP application servers use various memory buffers (table buffer, program buffer, etc.) to cache frequently-accessed data and avoid repeated expensive database or disk operations. Buffer tuning means sizing these buffers appropriately (via profile parameters) so they're large enough to avoid excessive swapping/reloading, but not so large they waste memory — monitored via ST02.
ST02 (Tune Summary/Buffer monitor) shows the current status and hit ratios of SAP's various memory buffers — helping administrators spot buffers that are too small (causing frequent, costly reloads/swaps) and need parameter adjustment.
Spool administration manages print/output requests — monitoring the spool work process, managing output devices/printers (SPAD), and troubleshooting stuck or failed print jobs (SP01/SP02) — a routine but important part of daily operational BASIS work.
Reactive monitoring means responding to issues after users report them or after they've already caused impact. Proactive monitoring means using alerting thresholds (via CCMS, Solution Manager, or third-party tools) to catch and address problems (like a buffer trending toward exhaustion) before they cause a user-facing incident — the maturity goal most BASIS teams aim for.
Start broad and narrow down: check SM50/SM66 for work process bottlenecks or queueing, ST03N for overall workload trends, ST04 for database-layer issues, and SM21/ST22 for any correlated errors or dumps around the same time window — cross-referencing these usually pinpoints whether the issue is application-layer, database-layer, or infrastructure-layer.
EWA is an automated, regular health-check report (typically weekly) generated via Solution Manager, covering performance, database growth, security configuration, and hardware capacity — giving BASIS teams a proactive summary of emerging risks across the landscape without manually running every check individually.
Single-system monitoring uses local transactions (SM50, ST03N) scoped to that one system. Landscape-wide monitoring (via Solution Manager or similar centralized tools) aggregates health and performance data across all connected systems, giving a unified view — essential once an organization runs more than a handful of SAP systems, since checking each individually doesn't scale.
HANA, DR, Archiving
Backup, Recovery & DB Administration
15 Questions
Protecting the data itself — backup strategy, recovery procedures, and the database administration fundamentals every BASIS professional needs, with a focus on modern HANA environments.
Full backup (complete copy of the entire database at a point in time), Incremental/Differential backup (only changes since the last full/incremental backup), and Log backup (transaction/redo log backups, taken frequently to enable point-in-time recovery between full backups).
A backup is a copy of data that can be restored if something goes wrong. Disaster recovery is the broader strategy and set of procedures (which may include backups, but also replication, standby systems, and failover processes) for getting the entire business back operational after a major outage — DR is the plan; backup is one tool within it.
RTO (Recovery Time Objective) is the maximum acceptable time to restore service after an outage. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured in time (e.g. 15 minutes of transactions). Together they drive how frequently you back up and what recovery technology (backup restore vs. live replication) is actually required.
Because HANA is in-memory, backups still need to capture a persistent, restorable copy — HANA supports full data backups, incremental/differential backups, and continuous log backups, similar in concept to traditional databases, but the restore process also needs to reload data back into memory, which is a distinct consideration for recovery time planning.
HANA Cockpit is SAP HANA's web-based administration tool for monitoring, configuring, and managing a HANA database — covering backup/recovery, user management, performance monitoring, and system configuration, largely replacing the older HANA Studio for day-to-day HANA-specific administration.
A restore brings back a specific backup file/image to the system. A recovery is the broader process of restoring a backup and then applying subsequent transaction/redo logs to bring the database forward to a specific desired point in time (point-in-time recovery) — restore is one step within the recovery process.
Regularly tracking database and individual table growth trends to anticipate storage capacity needs, identify unexpectedly fast-growing tables (which may indicate a data volume management issue or missing archiving), and plan infrastructure scaling before running out of space causes an outage.
SARA (Archive Administration) moves old, rarely-accessed data out of the live database into compressed archive files (still retrievable if needed), reducing the size of the active database and improving performance on frequently-queried tables — a key long-term strategy for controlling database growth in mature SAP systems.
A full backup restores directly. An incremental backup requires restoring the last full backup plus every incremental backup taken since, in sequence. A differential backup requires only the last full backup plus the single most recent differential — a trade-off between backup storage/time efficiency and restore complexity/time.
A standby database is a continuously (or near-continuously) synchronized replica of the primary database, ready to take over quickly if the primary fails — used in HANA System Replication for high-availability and disaster recovery scenarios, dramatically reducing RTO compared to restoring from backup alone.
HANA System Replication continuously streams changes to a standby system, enabling failover within minutes with minimal data loss (low RTO/RPO). A traditional backup-based DR strategy requires restoring from backup and replaying logs onto a fresh system when disaster strikes, which takes considerably longer but requires less continuous infrastructure investment.
Reviewing and cleaning old spool requests, batch job logs, and update records; managing transport directory growth; reviewing and archiving old application logs; and periodically reviewing database growth trends against archiving policies — routine but essential to prevent slow, silent performance and capacity degradation over time.
By periodically performing an actual test restore (ideally to a separate, non-production system) and validating the restored system is consistent and usable — not just confirming the backup job 'completed successfully'. It's often overlooked because it takes time and resources, but a backup that's never been test-restored is an unverified assumption, not a real safety net.
Running a database in archive/log mode means transaction logs are retained (rather than being immediately discarded after each checkpoint), which is what makes point-in-time recovery possible at all — without retained logs, you can only restore to the exact moment of your last full/incremental backup, losing everything since.
A cold backup requires the database to be shut down during the backup process, guaranteeing consistency but requiring downtime. A hot/online backup is taken while the database remains up and available to users, which is standard practice for most production SAP systems today given the downtime cost of cold backups.
SUM, DMO, RISE
S/4HANA Migration & Upgrades
15 Questions
The area of BASIS work with the highest demand right now — technical migration and upgrade skills are what every organization moving to S/4HANA needs, and interviewers know it.
New Implementation (greenfield — fresh S/4HANA system, reimplementing from scratch), System Conversion (brownfield — technically converting the existing ECC system in place, keeping historical data and much configuration), and Selective Data Transition/Landscape Transformation (a hybrid — selectively moving specific data/company codes into a new or existing S/4HANA system).
SUM is SAP's unified tool for performing system conversions, upgrades, and support package updates — it orchestrates the complex multi-phase technical process (including database migration when required) that would otherwise require many separate manual steps.
DMO is a SUM procedure that combines a system conversion (to S/4HANA) with a database migration (to SAP HANA) in a single, integrated process — rather than migrating the database first and converting the application separately, reducing overall project time and downtime.
Simplification Items document specific functional and technical changes between ECC and S/4HANA (e.g. table structure changes, deprecated transactions, new mandatory fields) that could affect existing custom code or configuration. Reviewing the Simplification Item catalog (via the Simplification Item Check) is a mandatory pre-check before any system conversion.
Support Packages deliver bug fixes, legal changes, and minor enhancements to standard SAP code; kernel upgrades update the underlying executable runtime. Both are typically applied using SPAM/SAINT (for support packages and add-ons) or via SUM for larger combined updates, following dependency checks from Maintenance Planner.
Since a system conversion/upgrade typically requires the system to be unavailable during the technical cutover, downtime optimization techniques (like SUM's Downtime-Optimized DMO, near-zero-downtime approaches, and pre-processing as much as possible before the actual cutover window) minimize business disruption — often the single most scrutinized metric in a migration project plan.
After a technical upgrade/conversion completes, validation confirms the system is functionally correct and performant — checking critical business transactions work as expected, verifying interfaces and background jobs resumed correctly, reviewing performance against pre-migration baselines, and confirming no unexpected short dumps or errors are occurring.
RISE with SAP is SAP's bundled offering combining S/4HANA Cloud, infrastructure (via hyperscaler partners), migration tooling, and managed services into a single contract — many organizations now migrate to S/4HANA specifically as part of a RISE engagement rather than a purely self-managed on-premise project.
BTP is SAP's cloud platform for building extensions, integrations, and analytics that connect to core S/4HANA without modifying the core system itself — BASIS teams increasingly need to understand BTP connectivity (via cloud connector, destinations) as more custom development moves to a 'clean core' extension model rather than in-system enhancements.
Clean core means minimizing custom modifications and enhancements directly inside the S/4HANA system, instead building extensions on BTP or via officially supported extensibility options — it matters for migration planning because heavily-modified 'dirty' ECC systems require significantly more remediation work (custom code adaptation) during conversion than cleaner ones.
Custom Code Migration (using the ABAP Test Cockpit / Custom Code Migration app) analyzes all Z-programs and custom enhancements against the target S/4HANA release's Simplification Items, flagging code that will break or behave differently — critical because unremediated custom code is one of the most common causes of post-go-live issues in system conversions.
A sandbox conversion is a trial run of the full technical conversion process against a copy of the production system, done well before the actual go-live, to surface unexpected issues (timing, custom code problems, data inconsistencies) in a low-risk environment — most well-run migration projects run several test conversions before attempting the real one.
Greenfield (new implementation) suits organizations wanting to shed years of accumulated customization and redesign processes around S/4HANA best practices, at the cost of a bigger reimplementation effort. Brownfield (system conversion) suits organizations wanting to preserve existing investment, history, and customization with less business process disruption, but carries more technical remediation work. The decision usually weighs business appetite for process change against project timeline and risk tolerance.
Executing the SUM/DMO technical procedure according to the rehearsed runbook, monitoring each phase for errors, coordinating timing checkpoints with the functional and testing teams, and being ready to troubleshoot or — if a go/no-go decision point is missed — support a rollback to the pre-migration state within the planned window.
SAP's stated end of mainstream maintenance for ECC (2027, with extended maintenance options beyond) has pushed a large wave of organizations into active migration projects simultaneously, and each project needs BASIS expertise for the actual technical execution (SUM/DMO, sizing, cutover planning) — a skillset that combines classic system administration with S/4HANA-specific migration tooling experience that not every BASIS professional has yet built.
Ready to Practice Out Loud?
Reading the answers helps.
Mock interviews make it stick.
Book a free 30-minute demo class — get personalized guidance on SAP BASIS interview prep, see live SAP training, and find out if VoiSAP is the right fit. No obligation.
Live SAP System Access
Real hands-on SAP BASIS training, not slides.
Career Support Included
Resume, LinkedIn, mock interviews, and job search strategy.
81% Placement Outcomes*
Built around the exact topics in this guide.
Canada-Focused
Brampton, Calgary, Mississauga, Kitchener and across Canada.
We received your request!
Our team will reach out within a few hours to schedule your free demo class.
No commitment required · Typically respond within a few hours