Retention and disposition
Qualified stakeholders must determine applicable rules, holds, privacy requirements and approved destruction.
Vendor-neutral reference designs
Five architecture patterns for governed historical data.
Compare source-attached archive access, independent historical platforms, hybrid federation, transaction-boundary carve-outs and governed AI access for ERP transformation and application retirement.
Core design principle: Separate current operations from governed historical access. Make the system of record, policy owner, provenance and shutdown authority explicit in every architecture.
| Pattern | Best fit | Primary control boundary |
|---|---|---|
| 1. Source-attached archive access | Active source application and targeted archive retrieval | Source application |
| 2. Independent historical platform | Application retirement or platform exit | Historical-data environment |
| 3. Hybrid federated access | Phased transformation and mixed active/retired estate | Shared policy across repositories |
| 4. Transaction-boundary carve-out | M&A, divestiture or legal-entity separation | Approved transaction perimeter |
| 5. Governed AI and agent access | Conversational or machine-assisted historical inquiry | Policy enforcement and semantic access |
How to read the diagrams
One visual language across five patterns.
Source
Operational application, native archive or content repository.
→Controlled transfer
Extraction, validation, reconciliation or approved movement.
Preserve
Structured data, documents, relationships and metadata.
⇢Governed access
Read-oriented query, reporting or supported integration.
Consumer
Authorized people, analytics or approved agent experiences.
Shared reference architecture
Historical access is more than a storage box.
A historical-data environment can contain preserved structured information, documents, relationships, metadata, reporting/search and supported integration services. Its control boundary must include identity, authorization, audit and lifecycle governance.
Sources
SAP and non-SAP applications
Documents and content stores
Controlled transferscope · extract · validate · reconcile
Historical-data environment
Structured history
Documents, relationships and metadata
Governed access
Search and reports
Supported APIs and integrations
Consumers
Business and audit users
Analytics and approved agents
Identity & authorization · Audit · Retention · Legal hold · Privacy controls · Disposition
Pattern 1
Source-attached archive access
Use when the originating application remains operational, archived records still depend on its business logic and users need occasional historical lookup.
Active source
Operational application
Native archivingeligible business objects
Archive estate
Archive files / store
Content repository and index
Native access
Approved archive viewers and reports
Consumers
Authorized application users
Source identity · Authorization · Archive administration · Retention · Access logging
Strengths
- Maintains native context and familiar access.
- Fits ongoing data-volume management.
- Limits near-term architectural change.
Tradeoffs
- Retains source technology and skills dependency.
- May not support full shutdown or cross-application reporting.
- Retrieval depends on native indexes and tools.
Decide
- Must the application remain for the retention period?
- Are records, documents and relationships retrievable?
- Are native reports sufficient for users and audit?
Pattern 2
Independent historical-data platform
Use when a legacy application is being retired, historical access must outlive the source technology or multiple systems need a consistent access model.
Shutdown candidate
Legacy ERP / application
retired after validation and approvalControlled preservationextract · reconcile · accept
Independent platform
Business-complete history
Documents and provenance
Historical services
Search, reports and evidence export
Consumers
Business, audit and support users
Platform identity · Authorization · Audit · Retention · Legal hold · Disposition
Strengths
- Decouples history from obsolete software.
- Supports shutdown and consistent access.
- Can consolidate multiple source systems.
Tradeoffs
- Requires semantic mapping and reconciliation.
- Native screens and executable logic are not automatically preserved.
- Ownership must transfer explicitly.
Decide
- Which objects, documents and calculations must survive?
- What evidence proves completeness and usability?
- Who authorizes shutdown?
Explore the historical data platform · Use the shutdown evidence checklist
Pattern 3
Hybrid federated historical access
Use when transformation is phased: some history remains in an active application or native archive while retired-system data moves to an independent platform.
Distributed records
Active ERP and native archive
Independent historical platform
Governed query routingsource-aware and read-oriented
Federation services
Metadata, source routing and provenance
Unified experience
Federated search and reporting
Consumers
Current + historical inquiry
Shared identity · Purpose · Result labeling · Correlated audit · Repository-specific retention
Strengths
- Supports phased modernization.
- Places data according to lifecycle stage.
- Enables combined current/historical inquiry.
Tradeoffs
- Creates multiple availability and policy dependencies.
- Cross-source definitions and joins can be difficult.
- A normalized screen does not mean identical source semantics.
Decide
- Which queries need multiple repositories?
- How will source and transformation be disclosed?
- What is the end state for source-bound data?
Pattern 4
Transaction-boundary carve-out
Use when a merger, acquisition, divestiture or legal-entity separation requires selected history to move while excluded information remains protected.
Shared estate
Enterprise applications and content
Perimeter classificationscope · separate · reconcile
Controlled dataset
Agreed transactions and supporting content
Separated access
Buyer / seller historical services
Consumers
Authorized deal, business and audit teams
Transaction rules · Privacy boundary · Exception approval · Transfer evidence · Retention
Strengths
- Aligns history with the transaction agreement.
- Can reduce indefinite TSA dependency.
- Creates evidence for included and excluded data.
Tradeoffs
- Shared entities and transactions create edge cases.
- Multiple parties must agree on definitions and acceptance.
- Privacy or contract terms may override technical completeness.
Decide
- What rules define the transferable population?
- How are shared records and documents handled?
- What proves completeness without over-disclosure?
Explore M&A historical-data separation · Use the reporting acceptance template
Pattern 5
Governed AI and agent access
Use when approved users or enterprise agents need conversational discovery or evidence retrieval across historical records while deterministic reports remain authoritative.
Governed history
Historical repositories and documents
Constrained retrievalidentity · purpose · authorization
Semantic access
Business glossary, retrieval and citations
Agent experience
Model gateway and approved tools
Consumers
Authorized users and human-approved actions
Pre-retrieval policy · Field/object permissions · Prompt/tool audit · Provenance · Human accountability
Strengths
- Improves discovery across complex historical estates.
- Can connect users to supporting records.
- Separates conversational exploration from authoritative evidence.
Tradeoffs
- Generated answers may be incomplete or incorrect.
- Entitlements, output controls and prompt-injection resistance require testing.
- Model, retrieval and policy changes need ongoing evaluation.
Decide
- Which uses permit summaries versus deterministic reports?
- Can material answers cite the underlying record?
- Which actions require human approval?
Explore ArchiveHub AI and agents · Review security and governance
Architecture decision framework
Narrow the choice with four questions.
- Must the original application remain?If yes, begin with source-attached access.
- Is shutdown an objective?If yes, favor an independent historical platform.
- Will data remain distributed during transition?If yes, use a hybrid pattern with an explicit end state.
- Is scope transactional or consumption machine-assisted?Add the carve-out or governed-agent pattern as an overlay.
Patterns can coexist. A carve-out can land in an independent platform; a hybrid estate can later expose governed agent access. Document which pattern owns each record, control and decision.
What diagrams do not decide
Architecture is not shutdown evidence.
Source coverage and fidelity
Discovery, mapping, extraction, documents, custom information and reconciliation remain source-specific.
Retirement authorization
Shutdown requires business acceptance, dependency closure, operating readiness and accountable approval.
Qualification: These conceptual patterns illustrate common deployment approaches. Actual source coverage, extraction method, hosting, controls, integrations, retention rules and retirement decisions depend on discovery, configuration and customer requirements. A diagram is not evidence that a source system may be shut down.
Frequently asked questions
Historical-data architecture questions.
Is a historical-data platform the same as a backup?
No. A backup is designed primarily for recovery. A historical-data environment is designed to preserve agreed business meaning and provide governed, usable access, reporting and lifecycle controls.
Is data archiving the same as operational migration?
No. Migration establishes information required in the target to run operations. Archiving removes eligible data from a live database while retaining supported access. Historical preservation keeps required closed history usable outside the operational target or after source retirement.
When can the source application be shut down?
Only after required information, documents, relationships, reports and dependencies have been preserved or resolved; validation and security controls are accepted; and accountable stakeholders approve the evidence-based shutdown gate.
How are attachments and documents handled?
Inventory repositories, links, metadata, versions and required file content separately from database tables. Test integrity, object association, authorization and retrieval in the intended post-cutover environment.
Can AI agents access historical data safely?
They can be evaluated through a governed pattern that enforces identity, authorization and purpose before retrieval; constrains tools and outputs; provides record-level provenance; audits activity; and requires human approval for controlled actions.
Choose the pattern with one real application in mind.
ArchiveHub can help map sources, historical user journeys, controls and retirement evidence into a target architecture.