How should IT handle old SharePoint data when every department wants to keep everything?

Treat old data as a business decision that IT runs as a service, not as a storage problem IT solves alone. Get the people accountable for each kind of record to agree how long it must be kept and why, write that down as one policy, and then let IT apply it through retention rules, archive tiers and deletion on a schedule.

Why this keeps landing on IT

When files move from an old file server into SharePoint, the question of what to keep usually travels with them, unanswered. Each department has its own site, its own year folders and its own instinct, which is normally "keep everything, just in case". IT ends up holding the bill for storage, versions and backups, while having no authority to say what can go.

The two tempting answers both go wrong. If IT decides alone, it is making legal and business calls it does not own. If each department decides alone, you get as many rules as you have departments, and nobody can say with confidence what the organisation keeps. John Sansbury makes the point about processes in general in The Journey to Service Excellence: "Without this role and the associated process policy, all you have is activities without any control." Retention is no different.

Practical steps

1. Name one owner for the retention policy. In a smaller organisation this is often the finance director, the head of operations or whoever owns compliance. They do not need to be technical. They need the authority to settle disagreements.

2. Ask each department for a reason, not a wish. For every main type of record, capture what it is, why it is kept, how people will look for it later, and how long it must be kept. Some periods come from law or regulators, some from contracts, and some are simply business preference. Label which is which, and check legal requirements with your adviser rather than from memory.

3. Agree tiers, not just a deadline. A simple model works for most: live (in SharePoint, editable), reference (read only, still searchable), archive (cheaper storage, retrieved on request), and delete. Decide who can ask for something back from archive and how quickly it should arrive.

4. Write a short policy. One or two pages: the owner, the record types, the retention period and its source, the tier rules, and how exceptions are requested and approved. Resist the urge to put step by step procedures in it.

5. Let IT implement and report. Retention policies and labels in Microsoft Purview can retain or delete content automatically; this is vendor material, so check what your licences include. Archive moves, version clean-up and backups then become routine operations with an owner and a schedule.

6. Review once a year. Departments change, regulations change and so does the cost of storage.

A short worked example

A firm moves to SharePoint and agrees that only the last three years go online. Finance says seven years for its records, and would quite like ten. The policy owner asks why. Seven years has a stated basis; the extra three are comfort. The agreed rule becomes: current and last two financial years live, years three to seven read only in an archive library, older years exported to archive storage with a deletion date, and anything with an open dispute held until it closes. Project teams, who look things up by client rather than by year, file by client instead, with the clock starting when the client relationship ends. IT builds the rules once and reports quarterly on what moved and what was deleted.

Common mistakes

• Confusing backup with archive. Backup is for recovering from failure; archive is the long-term, findable home for records you must keep.
• Letting every department write its own rules. Collaboration matters, but as John puts it, "collaboration does not mean consensus." Someone has to decide.
• Keeping personal data "just in case". The UK regulator is clear that you must not keep personal data longer than you need it, and should have a policy with standard retention periods.
• Ignoring versions. Large files edited often can quietly multiply storage through version history.
• Treating storage as a supplier problem. John contrasts a supplier, who will sell you more storage, with a partner who "will instead analyse the use of your disc storage and advise you which items to archive or delete on the basis that they have not been accessed for years or shouldn’t even be there." Aim for IT to play the partner role.

Where this fits in enterprise service management

This is enterprise service management in miniature: a business outcome (records kept safely, and only as long as needed), one accountable owner, a written policy, and IT running a reliable service against it. The same pattern works when HR, finance or legal want to manage their own requests and records.

If you want to compare approaches with others doing the same, the forums on ESM's Exchange are a good place to ask.

This answer draws on John Sansbury's The Journey to Service Excellence, which is available to members of ESM's Exchange.

Tags: esm-questions, data-retention, sharepoint, records-management, governance

Sources

• https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/

• https://learn.microsoft.com/en-us/purview/retention