When a company disappears: how to archive SharePoint, OneDrive and file shares after a takeover

When a company is taken over by a holding company, the IT department often focuses on the obvious things first: users, domains, mailboxes, licenses, applications and billing.

The old company may already be gone a few weeks later. The legal entity is dissolved, its SharePoint tenant is cleaned up and the last administrator is moved to another role. Then somebody asks for an invoice from eight years ago, an old customer contract or the project documentation for an audit.

That is the moment when the real question appears:

Where is the data of the old company, who can access it, and can the holding company prove that it has not been changed?

This is not a normal migration project. It is a controlled handover of records from one legal and organisational context into another one.

The focus of this article is SharePoint, OneDrive, file shares and local files. SAP and SQL are deliberately left out for now. The same principles apply there, but the technical archive process is different.

The first mistake: treating the takeover like a normal file migration

A normal migration asks questions such as:

• Which data do we still need?
• Which sites and folders should move?
• Which users need access?
• How much storage will it cost?

An archive project after a dissolution needs additional questions:

• Which legal entity created the records?
• Which obligations survive the dissolution?
• Which retention period applies to each type of data?
• Who is now the records owner?
• Which people from the holding company may access the records?
• Can the holding company show that the archive is complete?
• What happens if an auditor asks for access ten years from now?
• What happens if the original tenant, domain or identity system no longer exists?

This is why I would not simply copy everything into a new SharePoint site called Old Company Archive and declare the project finished. That may be a useful storage step, but it is not yet a defensible archive.

The legal entity may disappear, but the records do not

The holding company becomes the custodian of the data. It does not automatically become the original author of every document or the owner of every decision recorded in those documents.

That distinction matters. An old contract should still show which company signed it. An invoice should preserve its original context. A project decision should not appear as if it had been created by the holding company after the takeover.

The archive should therefore preserve at least:

• the original legal entity
• the business process or project
• the original source system
• creation and modification dates
• the final version or document package
• the person or role responsible at the time
• the new records owner in the holding company
• the applicable retention rule
• the date on which the retention period started
• the access history and any later disposition decision

This is where metadata is more important than a clever folder structure.

Ten years is not one universal retention period

In practice, people often say: “Keep the data for ten years.” That is a reasonable starting point for planning, but it is not a complete retention policy.

Different documents can have different clocks. The period may start at the end of a financial year, at the end of a contract, at the completion of a project or when a legal dispute is closed. Some documents may need to be kept longer. Other documents may have to be deleted earlier because there is no legal or business reason to retain the personal data.

For German tax and accounting records, the German Fiscal Code contains specific periods. For example, §147 AO currently distinguishes ten years for certain books and records, eight years for booking documents and six years for other documents listed there.[5] Commercial records are also covered by §257 HGB, including requirements around orderly storage and readability.[6]

That does not mean that every SharePoint file must be kept for ten years. It means the company needs a retention matrix that maps business record types to the legal or business rule that applies.

A sensible matrix contains at least:

This table is not a legal opinion. It is the control mechanism that makes the legal review and the technical implementation possible.

What is the archive in this scenario?

An archive is not just a place where old files are moved. For a dissolved company, it should provide four things:

1. Continuity: the information remains available even though the original company, tenant or employees no longer exist.
2. Context: the holding company can explain what the record is and where it came from.
3. Integrity: the archived version cannot be silently changed or deleted.
4. Controlled access: authorised auditors, legal staff and responsible administrators can retrieve the information without giving everybody access to the entire history.

The word independent is important here. Independence does not necessarily mean that the archive must be hosted by a different vendor. It means that the archive should not depend entirely on the same user account, administrator, production site and deletion process as the original working environment.

If the former tenant is deleted, the archive should still exist. If a former global administrator account is compromised, the archive should not automatically be editable. If the holding company changes its domain, the records should still be searchable and readable.

SharePoint and Microsoft Purview

SharePoint is often the best source and sometimes a suitable archive platform, especially when the records need to remain searchable and connected to their metadata.

Microsoft Purview Records Management supports retention labels, file plans, record declaration, disposition reviews and retention settings for documents and other content.[1] SharePoint and OneDrive content can be covered by retention policies or retention labels, including content in archived SharePoint sites.[2]

This is useful when the holding company wants to keep the data in Microsoft 365 and manage it with the same compliance tools. Microsoft 365 Archive can move inactive SharePoint sites into a lower-cost archive tier while keeping metadata, permissions and compliance features available.[3]

There is, however, an important limitation in the takeover scenario: keeping data in the same tenant is not the same as creating an independent archive. The archive still depends on the Microsoft 365 tenant, its licensing, its administrative model and its configuration.

SharePoint with Purview is a good choice when:

• the data must remain searchable
• the holding company already has a mature Microsoft 365 governance model
• the original site structure and metadata are still useful
• controlled access by legal, finance and audit teams is required
• the tenant will remain available for the full retention period

I would document the tenant dependency explicitly. It is not a reason to reject SharePoint. It is a reason to add another protection layer when the records are especially critical.

OneDrive is not a company archive

OneDrive is a personal working area. It is useful for drafts and for documents owned by an individual. It is a poor default destination for the long-term archive of a dissolved company.

The problem is not only storage. The problem is ownership and completeness.

• Which files are business records and which are personal working files?
• What happens when the user account is deleted?
• Who knows the contents of the personal OneDrive?
• Were files shared externally?
• Are there several final versions?
• Can the holding company explain why this particular OneDrive was complete?

Retention can apply to OneDrive content.[2] That is helpful, but retention alone does not turn a personal workspace into a well-governed company archive.

My recommendation is simple: treat OneDrive as a source that must be assessed. Move relevant business records into a controlled SharePoint location or an archive repository. Keep the original context in the metadata, but do not leave the long-term responsibility attached to one former employee.

File shares and local files

Classic file shares and local folders are often where the forgotten records are found. They may contain scanned contracts, exports, old project documents and files that never made it into SharePoint.

A file share can be part of the solution, but an ordinary folder is not automatically an archive. Typical weaknesses include:

• inherited permissions that nobody understands anymore
• files overwritten without a reliable version history
• missing business metadata
• no clear retention start date
• weak or incomplete audit logs
• local copies that are not included in the central inventory
• backups that exist, but cannot prove which version was authoritative

For local files, I would first build an inventory and create a controlled export. The export should include the files, source path, owner if known, timestamps, classification, checksum and transfer log. After verification, the archive copy should be protected against changes.

A file share can remain useful as a source or as a controlled access layer. I would not use it as the only long-term protection for critical records unless immutability, access separation and auditability are technically enforced.

Azure Blob Storage as an independent archive layer

Azure Blob Storage with Immutable Storage is a strong option when the holding company wants to separate the archive from the former production environment.

Azure supports WORM storage, which means that data can be protected from modification and deletion for a defined period. It also supports legal holds that remain active until explicitly cleared.[4]

A typical takeover process could look like this:

Former company data
  SharePoint / OneDrive / file share / local files
             |
             | inventory, classify, export, checksum
             v
Archive package
  files + metadata + source identity + transfer log
             |
             | separate archive roles and immutable policy
             v
Azure Blob Immutable Storage
             |
             | controlled retrieval and audit evidence
             v
Holding company audit access

This design gives the holding company a clearer separation between production and archive. It also makes it easier to explain who can read the records and who is prevented from changing them.

WORM is not magic, though. Before locking a retention policy, the organisation must test the retention periods, data formats, access model and deletion process. Microsoft distinguishes testable unlocked policies from locked policies. A policy should not be presented as a finished compliance control until the configuration has been reviewed and locked where required.[4]

The archive handover process

I would run the handover in controlled stages.

1. Freeze the source systems

Before the old company is dissolved, define a cut-off date. After that date, changes to the source data must either be blocked or recorded as part of the handover process.

Do not delete the old tenant or disable all administrative access before the export and verification are complete.

2. Build the inventory

List SharePoint sites, OneDrive accounts, file shares, local folders, external shares and known exports. Record the owner, data category, size, last activity and expected retention class.

This inventory is also the first completeness check. Without it, nobody can later say whether the archive contains all relevant sources.

3. Classify and remove obvious non-records

Temporary files, caches, duplicate downloads and personal material should not be pushed into a ten-year archive without review. Data minimisation still matters after a takeover. The GDPR principle of storage limitation does not disappear because a company has been dissolved.[7]

4. Create archive packages

For each business unit or record class, create a package containing:

• the original files
• metadata and source references
• the original legal entity
• the responsible business owner
• retention category and trigger date
• checksums
• export and transfer logs
• legal hold information, if applicable

5. Obtain the approvals

The business owner confirms completeness. Legal or records management confirms the retention rule. The data protection officer advises on personal data, access and deletion requirements. IT confirms the technical transfer and protection. The holding company formally accepts custody.

The data protection officer does not replace the records owner. Their role is to advise and monitor privacy compliance, not to certify that every business record is complete.

6. Transfer and verify

After transfer, compare checksums, open representative files, test search and test export. For long-term storage, include older file formats in the test set. A file that exists but cannot be opened ten years later is not a useful archive.

7. Lock and document

Once the checks are complete, activate the intended retention and immutability controls. Save the configuration, policy version, approvers, timestamps and test results with the archive documentation.

How auditors get access later

Auditor access should be designed before the original company disappears. The goal is not to give an auditor permanent access to the entire archive. The goal is to provide controlled, repeatable and documented access.

A practical model is:

1. The audit request gets a case or ticket number.
2. The responsible holding-company owner validates the scope.
3. Legal, compliance or data protection reviews whether the request is permitted.
4. A restricted audit group receives time-limited read access or a controlled export.
5. Every search, download and administrative action is logged.
6. The access is removed after the audit.
7. The request, approval, export and access log are retained as audit evidence.

The auditor should be able to see the relevant record and enough context to understand it. They do not automatically need access to unrelated personnel files or the complete archive of the dissolved company.

This is also where identities matter. A group named OldCompany-Audit is not enough. Document who can approve membership, who can use the group, how long access lasts and what happens when somebody changes role.

What the data protection officer should check

The data protection officer should be involved before the archive is built, not after the first audit request.

The review should cover:

• the purpose and legal basis for keeping the data
• data minimisation and exclusion of irrelevant personal files
• access groups and least privilege
• special categories of personal data
• former employee and customer data
• processors and cloud locations
• cross-border access by the holding company
• retention and deletion rules
• legal holds and exceptions
• audit logging and access transparency
• whether a data protection impact assessment is required

The archive may need to preserve data for a legal obligation, but that does not justify unrestricted access. Long retention and broad access are two separate decisions.

Audit checklist for the takeover archive

A useful audit process follows the complete chain, not just a few portal screenshots.

Scope: Which legal entity, systems, business units and years are included?

Completeness: Can the holding company prove that SharePoint, OneDrive, file shares and local source folders were inventoried?

Integrity: Are checksums, immutable policies or equivalent controls in place?

Context: Does every archive package identify the original company, source system and retention rule?

Access: Can the company show who may access the records and how temporary audit access is approved?

Retrieval: Can a sample record be found, opened, exported and explained?

Retention: Is the start of the retention period documented and are different record categories handled differently?

Disposition: Is deletion reviewed and documented when the period expires? Is a legal hold able to stop deletion?

Continuity: Would the archive still be available if the old tenant, domain or administrator account were removed?

The best test is a realistic one: ask a person who was not involved in the migration to find an old record using only the documentation and the audit process. If they cannot do that, the archive is not ready.

What I would not recommend

• deleting the former tenant before the archive is verified
• copying everything into one new SharePoint folder without classification
• keeping the archive in one former employee's OneDrive
• treating a backup as proof of retention and integrity
• keeping all personal data forever “just in case”
• using one global administrator account for archive access and deletion
• locking WORM policies before testing retrieval and retention dates
• allowing permanent anonymous or public links for auditor access
• giving auditors unrestricted access to the complete archive
• relying on screenshots instead of access logs, export records and test results

My practical conclusion

When a company is dissolved and taken over by a holding company, the archive becomes part of the successor's long-term responsibility. The original legal entity may disappear, but its contracts, accounting records, project history and evidence do not disappear with it.

For active work, SharePoint remains a strong platform. Purview can provide retention labels, records management and disposition controls. Microsoft 365 Archive can help with inactive SharePoint sites, but it remains inside the Microsoft 365 dependency model.

OneDrive should be treated as a source, not as the company archive. File shares and local folders need an inventory and a controlled transfer. For the most critical records, an independent archive layer with Azure Blob Immutable Storage can add the separation and technical protection that a simple SharePoint copy does not provide.

The important thing is not the product name. The archive needs a clear owner, a documented retention matrix, a controlled handover, restricted auditor access, technical integrity protection and a process that can still be understood ten years later.

That is the difference between storing old files and actually archiving the history of a company.

Sources

[1] https://learn.microsoft.com/en-us/purview/records-management [2] https://learn.microsoft.com/en-us/purview/retention-policies-sharepoint [3] https://learn.microsoft.com/en-us/microsoft-365/archive/archive-overview?view=o365-worldwide [4] https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview [5] https://www.gesetze-im-internet.de/ao_1977/__147.html [6] https://www.gesetze-im-internet.de/hgb/__257.html [7] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504