Sap ecc data archival into queryable Parquet on cloud object storage. Pre-cutover historical tail extracted from ECC, locked for SOX/HGB retention, accessed via standard SQL — so ECC can be switched off and the infrastructure freed.
Loading 15 years of BSEG into Fusion is wasteful. Keeping ECC running just for history is wildly expensive. Archival into a queryable cloud archive is the only sensible answer.
Every SAP ECC to Oracle Fusion programme runs into the same data-volume question around month four: how much history do we load into Fusion? The Fusion architects want a clean operational window — current FY plus the prior 1–2 FYs — because Fusion's query patterns, partition strategies and table layouts are tuned for that. The finance team wants 7 years (SOX). The German controller wants 10 years (HGB §257). The tax team wants whatever the country tax authority demands. The HR team has terminated-employee records going back 20+ years. Loading all of it into Fusion is the wrong answer — it bloats the tenant, slows reports, and forces Fusion to behave like an archive system it was never designed to be.
SAP's own archiving (SARA, ADK files, ILM rules) keeps the historical data on the SAP platform — fine if you intend to keep paying SAP licence and Basis maintenance indefinitely, useless if the whole point of the migration was to retire SAP. Custom data lakes solve the cost question but fail under audit pressure when the auditor wants a specific BKPF document from FY2017 and the data engineer has to reverse-engineer the cluster-table schema from scratch.
Syntra ETL's sap ecc data archival solves both. The historical tail beyond the Fusion operational window is extracted directly from ECC into queryable Parquet on cloud object storage, locked for the retention period required by SOX/HGB/IFRS/FDA/BaFin etc., and accessed through standard SQL via your existing analytics stack plus a lightweight transaction-style lookup app for auditors. The Fusion tenant stays lean. The ECC instance can be decommissioned. The audit obligations are satisfied. The infrastructure savings are realised in year one.
Why Parquet on cloud object storage beats SAP-platform-retained archiving in every dimension that matters.
Because the archive is independent of SAP, ECC can be decommissioned post-archival. SAP licence cancelled, Oracle/HANA DB licence cancelled, Basis team released, hardware/cloud-instance retired. 80–90% TCO reduction in year one.
Parquet is Apache-standard, read by every modern engine. ADK files are SAP-proprietary, readable only by an SAP system. Open format means the archive remains queryable for decades regardless of vendor changes.
Snowflake/Databricks/BigQuery/Athena/Trino/Presto all read Parquet natively. Tableau/Power BI/Looker connect through any of them. No SAP-specific tooling required for everyday lookups.
S3 Object Lock, GCS Bucket Lock, Azure Blob immutability — partitions locked for the configured retention. Satisfies SEC 17a-4(f), GoBD, MiFID II without separate compliance infrastructure.
Per-country company-code sharding at archive time. EU data in eu-central regions, US in us-east, APAC in ap-southeast. GDPR/GoBD/local privacy law compliant by design.
DD02L/DD03L dictionary snapshot, Z-* table catalogue, BAdI registry — captured at archive time and stored alongside the data. Future query knows exactly what every field means.
A repeatable workflow running alongside the Fusion migration. Total elapsed time: 6–12 months running concurrently with the Fusion programme.
Per data class, document retention requirement: SOX 7yr for financials, HGB §257 10yr for German books, IFRS, MiFID II, FDA, country tax authorities, employee records per jurisdiction. Sign-off from finance, HR, legal, external audit, country tax leads.
Per ECC table, decide split: stays-in-ECC (operational, loaded into Fusion), goes-to-archive (historical tail), goes-to-both (overlap period). Z-* tables classified the same way. Volume profile per partition produced.
Cloud archive infrastructure: object storage (S3/GCS/Azure Blob), KMS key strategy, network connectivity, query engine, WORM-lock policy, lookup app deployment. Data-residency partitioning designed.
Concurrently with the Fusion migration, archival extracts run on a rolling schedule: fiscal years 0–7 first (the most recent closed history), then 7–15+ second (deep historical tail), then HR retention tail. Parquet partitions WORM-locked as they land.
Internal audit, external audit and country tax-team representatives sample-test the archive against the still-live ECC system: specific BKPF docs, customer aging snapshots, asset register, GL trial balances — all reproduce identically. Sign-off pack issued.
Post-cutover, the final ECC-to-archive delta runs (the last 1–2 fiscal months that lived in ECC during parallel-run). Archive sealed. ECC decommissioned: licences cancelled, Basis released, hardware retired.
Every module that mattered in ECC has a defined archival profile aligned to the relevant retention rules.
BKPF doc headers, BSEG line items, BSAD/BSID/BSAK/BSIK opens & cleared, currency translation, multi-ledger postings. 7yr SOX / 10yr HGB / IFRS as applicable, WORM-locked.
CSKS cost centres, AUFK orders, CEPC profit centres, COSP/COSS line items, COPA operating concern. Retained alongside FI for SOX trace continuity.
MARA/MARC/MARD master, EKKO/EKPO purchase docs, MSEG goods movements, batch and serial-number history. 7–10yr typical with tax and product-liability rules.
VBAK/VBAP orders, VBRK/VBRP billing, KONV conditions, LIKP/LIPS deliveries, VBFA document flow. 6–10yr per VAT and revenue-recognition audit rules.
ANLA/ANLC asset master and value, depreciation history, post-capitalisation context. Held through asset-life + relevant tax-window post-retirement.
HRP1000 org, PA0000-series infotypes, PCL2 payroll cluster, terminated-employee records. 7–50+yr depending on jurisdiction (German pension obligations push longest).
Sap ecc data archival is the practice of moving historical SAP ECC data — typically pre-cutover transactional history that does not need to live in the target Fusion tenant — out of the source ECC system into a queryable long-term archive, so that the ECC instance can be decommissioned without losing audit-required history. It is different from migration (which moves data into Fusion as the operational system of record) and different from SAP's own SARA-based archiving (which keeps data on the SAP platform). In a Fusion migration, sap ecc data archival typically covers everything older than the operational window loaded into Fusion (commonly current FY + prior 1–2 FYs) — meaning 7–15 years of GL line items, customer history, vendor history, asset history and HR records get archived rather than loaded into Fusion.
Two reasons: infrastructure cost and Fusion-tenant hygiene. Loading 15 years of BSEG line items, every closed sales order, every retired asset and every terminated employee into Fusion bloats the tenant unnecessarily — Fusion is optimised for current operational data plus a window of analytical history, not for long-term audit retention. Meanwhile, keeping ECC running purely to hold history is wildly expensive (HANA or Oracle DB licence, SAP application maintenance at 22% of licence, Basis team, hardware/hosting). Archiving the bulk of ECC history into a cloud archive while loading only the operational window into Fusion gives you the best of both: a lean Fusion tenant that performs well, and a compliance-grade archive that costs 8–12% of what running ECC was costing.
SAP's native archiving (SARA transaction, ADK files, ILM rules) keeps the archived data on the SAP platform — archive runs move records from hot tables into compressed ADK files on the SAP file system, but the SAP application is retained as the lookup mechanism so you keep paying SAP licence and Basis support. Syntra ETL's sap ecc data archival extracts data fully out of SAP into open Parquet on cloud object storage, accessed through standard SQL via your existing analytics stack (Snowflake/Databricks/BigQuery/Athena) plus a lightweight transaction-style lookup app. Same regulatory coverage, fraction of the operating cost, and no SAP platform dependency. The ECC instance can be turned off entirely once archival is validated.
The pre-cutover historical tail — anything older than the operational window being loaded into Fusion. Closed BKPF/BSEG GL line items beyond the loaded fiscal years. Cleared AR/AP items (BSAD/BSAK) from prior periods. Retired customers and vendors (KNA1/LFA1 records with no recent activity). Retired assets (ANLA records past the depreciation tail). Closed sales orders and old billing (VBAK/VBAP/VBRK/VBRP). Historical goods movements (MSEG/MKPF). Terminated employees in HR (PA0000-series with terminated status). PI/PO interface logs and IDoc payloads from prior years. Plus the customisation snapshot (DD02L/DD03L Z-* catalogue) so the schema of the archived data is documented for future query.
Per the applicable retention obligation. SOX requires 7 years for financial records with auditable trace. German HGB §257 + AO §147 require 10 years for accounting records, supporting documents, journals and inventories (Aufbewahrungspflicht — non-negotiable). EU VAT rules typically require 6–10 years depending on member state. UK HMRC requires 6 years. US IRS expects 7 years for most records. FDA 21 CFR Part 11 (pharma) requires record retention through product lifecycle plus 1–5 years post-discontinuation. Employee records can require 7–50+ years depending on country (Germany lifetime + 30 for some categories). The archive is configured per data class with the longest applicable retention, and WORM-locked accordingly.
Fully queryable. Sap ecc data archival into Syntra ETL's archive means the data lands as columnar Parquet on object storage with full schema metadata in a Glue/Hive/Databricks catalog. Any SQL engine reads it natively: Snowflake external tables, Databricks Delta Lake or direct Parquet read, BigQuery federated tables, Athena, Trino, Presto, Starburst. Tableau, Power BI, Looker connect through any of those. For auditors who want SAP-style browse-and-drill rather than SQL, the archive ships with a lookup app providing transaction-style navigation against the Parquet store (browse customer, drill to open items, drill to original document). Same data, two access patterns.
Compliance is configured per data class at archive time. SOX 7-year retention applies to financial records (BKPF/BSEG, BSID/BSIK, etc.), with WORM-lock on the partitions and a signed audit-trace from any archive read back to the original ECC document and supporting evidence. German HGB §257 + AO §147 10-year retention applies to accounting records, with §238 HGB requirement for orderly book-keeping preserved through the schema documentation. Country-specific extensions (Italian SDI, Brazilian SPED, Polish KSeF, Mexican CFDI) carry their own compliance flags so country auditors get the country-format extracts they expect. Read-access is logged to your SIEM for SOC 2 and forensic audit trail. Tamper-evident throughout.
Yes — and that is the recommended pattern for a phased Fusion programme. While ECC remains operational (months 1–12 of the migration), sap ecc data archival runs on a regular schedule extracting completed historical periods into the archive (closed fiscal years, cleared documents, retired master data). This serves three purposes: (1) builds the archive incrementally so the cutover-day archive operation is small and low-risk, (2) gives auditors and tax authorities a queryable archive while ECC is still live (useful for current-period inquiries), and (3) reduces the operational load on ECC by allowing safe SARA-style hot-table cleanup once data is verified in the archive. Post-cutover, the final historical delta is captured and the archive is sealed.
30-minute discovery call. We'll scope your ECC data volume, retention obligations per module and per country, target cloud architecture, and produce an archival timeline that runs in parallel with your Fusion migration.