The new cloud-based data warehouse is up and running, the reports are accurate, and the migration project is officially complete. Nevertheless, the Teradata system is still in place at the data center. No one wants to commit to the fact that the data from past years is no longer needed there, so the license, maintenance, and operations simply continue. This article shows how you can decommission Teradata while still being able to respond to any requests from business units, auditors, and tax auditors.
KEY POINTS AT A GLANCE
|
Why Companies Are Shutting Down Teradata Now
Anyone replacing a Teradata data warehouse that has grown over the years must deal with load processes, data models, and reports that are often spread across many departments. When switching to a cloud platform, this therefore creates two separate tasks: migrating ongoing analytics and properly shutting down the legacy system.
IT service providers describe what this process might look like in their case studies. Persistent Systems reports on a U.S. healthcare company that operated Teradata on-premises for more than two decades and was only able to completely decommission the system after all users had migrated. Hexaware describes a Belgian insurer whose data warehouse appliance had reached its capacity limit and whose maintenance costs were driving up total costs significantly.
The real bottleneck rarely lies in the migration itself. Computerwoche summed this up as early as 2014: Many legacy systems are kept in operation solely because of the data stored within them. This is precisely what application retirement is for—the controlled decommissioning of a system whose data remains available elsewhere. You can find the basics on this topic in the article “Replacing Legacy Systems.”
Migration Is Not Archiving: The Most Common Fallacy
In CSP customer projects, the same pattern emerges time and again: migration is selective. Current data models, data loads, and the reports used on a daily basis are migrated to the new platform. Historical detail data—such as closed fiscal years, transaction data from earlier periods, or accounts of former customers—is often left behind, however, because converting it to the new schema is time-consuming and no one in day-to-day operations asks for it.
However, it is precisely this data that is often subject to retention requirements. As long as it remains in the Teradata system, it cannot be decommissioned. It therefore makes sense to make a clear distinction: Migrate what will continue to be analyzed. Data that only needs to be retained and occasionally retrieved belongs in an archive. The article “Greater Efficiency in Cloud Migration” describes how selective archiving streamlines a cloud migration.
TYPICAL PRACTICAL MISTAKEAfter migration, the legacy system is set to read-only and continues to operate as an archive. This means that the license, hardware, operating system, and specialized knowledge for Teradata SQL continue to be required, and with each passing year, it becomes more difficult to find replacement parts, patches, and experts. Read-only access does not automatically turn a production database into an audit-compliant archive. |
A backup is also no substitute for an archive. A backup is used to restore a system, while an archive provides long-term, auditable access to individual data records. The article “Backup vs. Archiving” explains the difference in detail.
What retention requirements apply to Teradata data?
Whether a data warehouse contains data subject to retention requirements is determined by its content, not by the technology used. Section 147(1) of the German Fiscal Code (AO) explicitly mentions, in addition to books, accounting documents, and business correspondence, other documents as well, provided they are relevant for tax purposes. Inventory movements, billing data, and transaction statements—which are stored in many data warehouses—typically fall under this category.
| Document Type | Retention Period | Legal Basis |
|---|---|---|
| Books, records, inventories, financial statements | 10 years | Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB) |
| Accounting documents (e.g., invoices, receipts) | 8 years as of January 1, 2025 | § 147(3) AO, § 257(4) HGB as amended by BEG IV |
| Transaction records from banks, insurance companies, and securities firms | 10 years | Reversal of the reduction for the financial sector (Bundestag resolution of November 13, 2025) |
| Incoming and outgoing commercial and business correspondence | 6 years | Section 147(3) AO, Section 257(4) HGB |
| Personal data without a retention requirement | Only as long as necessary for the purpose | Art. 5(1)(e) and Art. 17 of the GDPR |
Two details extend the retention periods in practice. First, pursuant to § 147(3), sentence 5, AO, the retention period does not expire as long as the documents are relevant for taxes for which the assessment period is still ongoing. Second, the retention period does not begin until the end of the calendar year in which the document was created. For data from a Teradata system that was in operation for ten or fifteen years, this results in staggered deletion dates spanning many years.
The GDPR takes the opposite approach. Personal data may only be stored for as long as necessary to fulfill the purpose for which it was collected. A statutory retention obligation is a permissible reason under Article 17(3)(b) of the GDPR to retain data for a longer period, but this obligation ends when the retention period expires. An archive must therefore manage retention periods for each data class and be able to delete data selectively once these periods have expired. You can find an overview of all retention periods in the article “Retention Periods According to the German Commercial Code (HGB), the GDPR, and the GoBD.”
Data Governance for Structured DataThis white paper shows how to manage structured data from databases throughout its lifecycle and establish transparent rules for retention and deletion. |
What does “audit-proof” mean in the context of database data?
The term “audit-proof” does not appear as such in the law. It summarizes the requirements of the German Fiscal Code (AO) and the German Principles of Sound Accounting (GoBD) for electronically stored documents. According to Section 147(2)(2) of the German Fiscal Code (AO), the data must be available at all times throughout the entire retention period, must be made readable immediately, and must be capable of being evaluated by machine. The GoBD, as set forth in the Federal Ministry of Finance (BMF) letter dated November 28, 2019, supplements these requirements with provisions regarding immutability, traceability, and protection against loss and tampering.
For database data, this means specifically: The tables alone are not sufficient. The data is only verifiable if the relationships between the tables, the field definitions, and the queries used to trace a business transaction are also preserved. Anyone searching for a document related to a goods movement from 2019 needs header data, line items, master data, and the posting in context.
Data Access by Tax Authorities Following Decommissioning
Section 147(6) of the German Fiscal Code (AO) provides tax auditors with three ways to access electronic records: They may view the stored data themselves using the system; they may have the data analyzed according to their specifications; or they may have the data transferred to them on a machine-readable data carrier. In practice, these are referred to as Z1, Z2, and Z3 access.
The same provision contains an important exemption for system changes. If a data processing system is changed or data is migrated from the production system, it is sufficient, after the expiration of the fifth calendar year following the transition, to retain the data only on a machine-readable and machine-processable data carrier, provided that no external audit has begun by that time. Conversely, full access must be guaranteed during the first five years following the decommissioning of Teradata. An archive with a search interface meets this requirement, whereas a batch of export files generally does not.
| Criterion | Database Dump | CSV Export | Audit-compliant database archive |
|---|---|---|---|
| Readable without a running Teradata instance | No | Yes | Yes |
| Preserves relationships between tables | Yes | No, only individual tables | Yes |
| Search by department | no | Limited | Yes |
| Protection against subsequent modification | Depends on the storage location | No | Yes |
| Retention periods and deletion by data class | No | No | yes |
The article “Audit-Compliant Archiving: Choosing the Right Software” explains what you should consider when selecting a solution. You can find detailed information on tax requirements under “GoBD-Compliant Archiving.”
Decommissioning Teradata in Six Steps
The following sequence has proven effective in decommissioning projects. It can be initiated in parallel with the migration to the new platform so that the legacy system does not remain operational any longer than necessary.
1. Take inventory
Identify databases, tables, data volumes, load processes, and all systems that still access Teradata for reading or writing. It is also important to determine which business units still initiate historical analyses today and how often.
2. Classify data
Assign each table to one of three categories: migrate, archive, or delete. For archived data, define the retention period for each data class and flag any personally identifiable information so that it can be deleted in a timely manner later on.
3. Define the Archiving Model and Search Criteria
Work with the business units to determine which search forms, queries, and reports must be available in the archive. Involving future users early on saves rework and prevents tickets from ending up with IT again. The article “Archive Access Without an IT Ticket” shows how business units can access archives on their own.
4. Extract Data
Teradata offers its own tools for large volumes. According to the manufacturer’s documentation, the Teradata Parallel Transporter’s Export Operator extracts large amounts of data at high speed and can run in multiple parallel instances, similar to the FastExport tool. Log each run with the number of rows per table, as you’ll need these figures in the next step.
5. Verify Completeness and Approve
Compare the number of records and the totals of key fields between the source and the archive, and perform a business-logic check on a sample basis. Document the results and have them approved by the responsible parties before the legacy system is taken offline.
6. Shut down and document
Update the GoBD-compliant procedural documentation to include the archive, document the deletion policy, and cancel licenses and maintenance contracts. Also, record the date of the migration, as this is the starting point for the five-year period specified in Section 147(6) of the German Fiscal Code (AO). For more information on decommissioning legacy systems, see the article “Decommissioning a Legacy System.”
Case Study: Teradata Data Warehouse with Billions of Goods Movements Decommissioned
In July 2014, Computerwoche described how such a shutdown works, using the example of the insolvent drugstore chain Schlecker. The insolvency administrator needed to be able to provide data to the tax office, the pension insurance agency, and for insolvency proceedings for years to come, but wanted to reduce the operating costs of the legacy systems as quickly as possible. Until then, there had been no electronic archive for the databases; all data was stored in the production systems.
According to the report, CSP prepared seven systems for decommissioning, including the Navision ERP system, a heavily customized AS/400 system, an intranet, and a Teradata data warehouse. A separate database archive based on the standard CHRONOS software was created for each system. Search forms, queries, and reports were tested with the business departments and approved by the insolvency administrator. The project ran in parallel with normal operations and was completed after just a few months.
The first system to be decommissioned was the Teradata data warehouse, which stored billions of inventory transactions from the drugstores. Subsequent searches were conducted using the CHRONOS Archive Explorer, a unified interface across all archived systems. Results can also be downloaded in XLS and IDEA formats, which, according to the report, is particularly beneficial to the business departments.
“The fact that the database archive consolidates all previous systems into a single, unified system […] is particularly valuable.”
Markus Bartsch, then head of the legacy system migration team, in *Computerwoche* (2014)
This example illustrates what matters most: The data remains complete and searchable, while the legacy system—along with its ongoing costs—is phased out. What an insolvency administrator had to implement under time pressure applies just as much to companies that operate multiple data warehouses in parallel following a cloud migration or a merger. You can find more about CHRONOS on the page Database Archiving with CHRONOS.
Continued Operation or Archiving: A Comparison
Specific savings depend on the licensing model, hardware, and data volume and can only be calculated on a case-by-case basis. However, the cost components themselves are the same for every project.
| Criterion | Continue operating Teradata | Archive data and shut down Teradata |
|---|---|---|
| License and vendor support | continue | No longer applicable |
| Hardware, data center, operating system | continue to operate; replacement becomes more difficult as they age | N/A |
| Specialized knowledge for administration and Teradata SQL | must be maintained | Searching via search forms without SQL knowledge |
| Access for the business unit | usually only through IT | directly via the search interface and exports |
| Deletion after the deadline | usually manual or not at all | can be controlled by data class |
| Data access pursuant to Section 147(6) of the German Fiscal Code (AO) | via the legacy system | via the archive |
The article “Why Database Licenses Drive Up IT Costs” describes the extent to which database licenses strain the IT budget. To learn about the risks of not archiving data at all, see “Costs of Non-Archiving.”
Checklist Before Shutting Down Teradata
|
Frequently Asked Questions About Decommissioning Teradata
Is it okay to shut down Teradata once all active data has been migrated?
Only if the historical data subject to retention requirements is also available, readable, and machine-readable elsewhere. According to Section 147(2) of the German Fiscal Code (AO), this applies for the entire retention period. If this data is not migrated, it must be transferred to an audit-proof archive before the system is decommissioned.
How long must data from a Teradata data warehouse be retained?
That depends on the content. Books and annual financial statements must be retained for ten years; accounting documents, starting in 2025, for eight years; and business correspondence for six years (Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB)). Banks, insurance companies, and securities firms continue to retain accounting documents for ten years. The retention period does not expire as long as the data is relevant to pending tax assessments.
Is a database dump sufficient for audit-proof archiving?
Generally not. A dump can only be read using a running Teradata installation and does not allow for searches by business unit or auditor. An audit-proof archive keeps the data available independently of the legacy system, protects it from modification, and makes it machine-readable.
What kind of data access does the tax audit require after the system has been decommissioned?
Under Section 147(6) of the German Fiscal Code (AO), the tax authorities may access the data themselves, have it analyzed according to their specifications, or request a data carrier. Following a system change, it is sufficient to provide the data on a machine-readable data carrier only after the fifth calendar year following the transition has elapsed, provided that no on-site audit has begun by that time.
How long does it take to decommission a Teradata system?
That depends on the volume of data, the number of tables, and the coordination effort required with the business units. In the Schlecker project described by Computerwoche, CSP prepared seven systems—including a Teradata data warehouse—for decommissioning within a few months, while operations continued uninterrupted.
What happens to personal data in the archive?
According to Article 17(3)(b) of the GDPR, it may be retained for as long as a legal obligation exists. After that, it must be deleted. An archive should therefore manage retention periods for each data class and be able to selectively delete expired data records.
Conclusion: Archive first, then deactivate
A Teradata system can only be decommissioned once its historical data has been securely stored elsewhere. Planning migration and archiving separately from the outset saves the years during which the legacy system would otherwise remain operational solely for occasional lookups. The retention requirements under the German Fiscal Code (AO) and the German Commercial Code (HGB), the five-year rule for data access, and the deletion requirements of the GDPR provide the framework for this. An audit-compliant database archive meets these requirements and provides business units and auditors with direct access to the data.
Your Teradata Archive in a Live DemoSee live how CHRONOS retrieves historical data from a data warehouse and makes it searchable for business units and tax auditors. |
Sources
- § 147 of the German Fiscal Code, Regulations Governing the Retention of Documents
- EY Tax News: Longer Retention Periods for Banks, Insurance Companies, and Securities Firms
- KPMG VAT Newsletter October 2024: Fourth Bureaucracy Reduction Act
- Forum Verlag Herkert: Retention Periods for Businesses (November 12, 2025)
- General Data Protection Regulation (EU) 2016/679, Art. 5 and Art. 17
- Federal Ministry of Finance (BMF) Letter dated November 28, 2019: Principles for the Proper Maintenance and Retention of Books, Records, and Documents in Electronic Form (GoBD)
- Computerwoche: Beyond the End. Why Anton Schlecker Still Needs IT (July 22, 2014)
- Teradata Documentation: Parallel Transporter User Guide, Producer Operators
- Persistent Systems: From Teradata to the Cloud (Case Study)
- Hexaware: Teradata to Azure SQL Data Warehouse Migration (Case Study)
Responsible for strategy and innovative software solutions for the manufacturing industry.