A BI platform decommissioning checklist should include a pre-retirement audit, data migration and archiving steps, user access revocation, compliance documentation, and a final validation process. These steps ensure that retiring a BI platform does not result in data loss, compliance gaps, or disruption to business users who depend on the reports and dashboards it hosts.
The stakes are especially high in regulated industries, where incomplete decommissioning can trigger audit findings or legal exposure. Whether you are sunsetting QlikView in favour of Qlik Cloud or retiring a legacy Power BI environment, a structured checklist keeps the process controlled and accountable. The sections below walk through each phase of that checklist in detail.
What steps should come before decommissioning a BI platform?
Before decommissioning a BI platform, you should complete a full inventory of all applications, data sources, and active users, assess which assets need to be migrated versus archived, communicate the timeline to stakeholders, and confirm that a target environment is ready to receive any content being moved. Skipping these steps is the most common cause of failed platform retirements.
Start by pulling a complete list of every app, report, and dashboard hosted on the platform. For each asset, determine whether it is actively used, dormant, or entirely obsolete. Usage data is your best guide here: assets that have not been opened in six months or more are strong candidates for archiving rather than migration.
Once you have that inventory, map every data source connection. Understand which pipelines feed the platform and whether those connections need to be redirected to a new environment or simply closed. Broken data connections on a successor platform are a common post-migration headache that pre-decommissioning mapping prevents.
Finally, set a clear timeline and communicate it broadly. Business users who rely on specific reports need enough notice to adapt their workflows. Internal teams handling the migration need realistic deadlines. A well-communicated plan reduces resistance and avoids last-minute scrambles.
What data and content need to be migrated or archived during a BI platform migration?
During a BI platform migration, you need to migrate or archive application files, data models, embedded scripts, connection strings, published reports, and any custom themes or extensions. Content that is actively used should be migrated to the successor platform; content that is no longer needed but must be retained for compliance should be archived in a retrievable format.
The distinction between migration and archiving matters. Not everything deserves a place in your new environment. Carrying over unused or outdated reports inflates maintenance overhead and clutters the new platform before it even launches. A clean migration is a deliberate one.
Content to migrate
Prioritise reports and dashboards with active users, applications tied to ongoing business processes, and any content that stakeholders have explicitly requested in the new environment. Verify that data source connections are reconfigured and tested before marking any asset as successfully migrated.
Content to archive
Archive reports that are no longer actively used but may be needed for historical reference or audit purposes. Store archived content in a format that is readable without the original platform, and document where each archived asset lives so it can be retrieved if needed. Version history, where available, should be preserved alongside the final application state.
How do you handle user access and permissions during decommissioning?
During BI platform decommissioning, user access should be progressively restricted as the retirement date approaches, with full revocation completed before the platform is taken offline. Permissions should be audited before decommissioning begins to ensure that access to the successor platform is correctly configured for every affected user.
Begin by exporting a full list of current users and their permission levels. Cross-reference this list against your target environment to identify gaps: users who need access to the new platform but have not yet been provisioned, and users who should not carry over at all.
Set a date for read-only access on the legacy platform, followed by a hard cutoff date. This two-stage approach gives users time to retrieve anything they need while preventing new work from being done in a system that is about to be retired. Communicate both dates clearly and provide a point of contact for users who have questions.
Do not forget service accounts and automated processes. Scheduled reports, API integrations, and data refresh jobs often run under technical accounts that are easy to overlook. Failing to revoke or redirect these can leave orphaned processes running against a decommissioned system, which creates both security and data integrity risks.
What governance and compliance requirements apply to BI platform retirement?
BI platform retirement must satisfy any data retention obligations, audit trail requirements, and access control standards that apply to your industry. For organisations operating under frameworks such as HIPAA or Sarbanes-Oxley, decommissioning must be documented in a way that demonstrates controlled, auditable change management throughout the process.
At a minimum, governance requirements for platform retirement typically include:
- Documented approval: A formal sign-off from relevant stakeholders confirming the platform is ready to be retired
- Change log: A record of every action taken during the decommissioning process, including who performed it and when
- Data retention confirmation: Evidence that all data subject to retention requirements has been preserved in a compliant format
- Access revocation records: Documented proof that all user and service account access was removed before the platform went offline
- Security sign-off: Confirmation from your security team that the decommissioned platform no longer poses a vulnerability
If your organisation operates in a regulated industry, involve your compliance team early. They may have specific documentation templates or sign-off requirements that need to be built into your decommissioning timeline rather than addressed at the end.
How do you validate that a BI platform has been fully decommissioned?
A BI platform is fully decommissioned when all content has been migrated or archived, all user access has been revoked, all data connections have been closed or redirected, and no automated processes are still referencing the retired environment. Validation should be confirmed through a formal checklist sign-off rather than assumed.
Run a final check across each of these areas before declaring the decommissioning complete:
- Content verification: Confirm that every asset marked for migration exists and functions correctly in the new environment
- Archive confirmation: Verify that archived content is stored, labelled, and retrievable
- Access audit: Run a permissions report on the legacy system to confirm zero active users or service accounts
- Connection sweep: Check that no active data pipelines or scheduled jobs are still pointing to the retired platform
- Network and infrastructure: Confirm with your IT team that the server or cloud instance has been shut down and is no longer accessible
- Documentation complete: Ensure all governance records, approval logs, and compliance documentation are filed and accessible
After sign-off, retain the decommissioning documentation according to your organisation’s standard retention policy. If an audit question arises later, you want a clear paper trail showing that the retirement was handled in a controlled, deliberate way.
How PlatformManager supports controlled BI platform migration
Retiring a BI platform is significantly easier when your environment has been managed with governance and version control from the start. That is exactly where we come in. PlatformManager’s BI governance solutions give teams the audit trails, version histories, and deployment controls that make decommissioning a structured process rather than a stressful scramble.
Here is what we bring to a BI platform migration or retirement project:
- Full lifecycle reporting: Every app’s history is documented, giving you a clear picture of what exists, who uses it, and when it was last modified
- Automated deployment controls: Move content from one environment to another with confidence, knowing that approval steps and testing are enforced before anything goes live
- Data lineage tracking: Understand exactly which data sources each app depends on, so no connection is missed during migration
- Compliance-ready documentation: Built-in change tracking produces the audit evidence that regulated industries require
- Multi-platform support: Whether you are migrating from QlikView to Qlik Cloud, or consolidating Power BI and SAP BusinessObjects environments, we manage it all from a single installation
If you are planning a platform retirement and want to make sure nothing falls through the cracks, get in touch with us to discuss how we can support your decommissioning process from start to finish.