Introduction
Archiving an ActivityInfo database is a deliberate process of preserving historical data while preventing further modification. Rather than deleting a database, ActivityInfo encourages maintaining it as a stable reference point for reporting, audits, and future comparisons.
There are many situations where an organization may need to archive an ActivityInfo database. In most cases, active data collection or reporting has ended, but the information still needs to remain accessible for historical reference, audits, reporting, or future analysis.
Common scenarios include:
- End of a donor funded project after final reporting and closeout.
- Transition to a new reporting period.
- Completion of baseline, midline or endline surveys.
- Migration to a redesigned database structure or reporting framework.
- Transition from pilot implementations to production.
- Preservation of validated datasets.
This article brings together key steps and best practices to transition a database into an archived state effectively.
Transition users to read only access
The foundation of archiving a database begins with controlling what users are allowed to do. In ActivityInfo, access is governed through roles, which define permissions such as viewing, adding, editing, or deleting records.
To archive a database:
- Remove permissions for adding, editing, and deleting records.
- Retain viewing permissions so users can still analyze and report on data.
- Limit management and design permissions to the database owner.
This ensures that users can continue working with the data for reporting and analysis, but cannot make changes that would compromise the database integrity.
Apply locks to enforce data protection
ActivityInfo allows you to apply locks that prevent changes regardless of user roles.
Locks can be applied at different levels:
- The entire database
- Folders
- Forms or subforms
Once a lock is configured, users cannot add, edit, or delete records within the locked scope. This makes locks essential for:
- Freezing datasets
- Preventing accidental or malicious edits
- Ensuring consistency across reporting periods
Even if a user retains edit permissions, locks override them, providing a strong safeguard during archival.
Clearly mark the database as archived
When archiving an ActivityInfo database, communication is a key step. Renaming helps users immediately understand that a database is no longer active.
You can rename databases, folders and forms to help users understand that the resources are within a closed period. Some examples include:
- [ARCHIVED] - Country X Malaria Program 2022 - 2024
- [CLOSED] - Nutrition Surveillance - 2025
Review the audit log
Before fully retiring the database, it is good practice to review the audit log. This provides a detailed history of:
- Data changes
- Permission updates
- Structural modifications
This acts as a verification step, ensuring that the database is complete, consistent, and ready to be preserved in its final state.
Prepare for future reporting needs
In some cases, retiring a database marks the end of a reporting period and the start of a new project.
ActivityInfo supports the duplication of the database structures, allowing you to create new database structures for the new reporting cycle.
This approach ensures continuity while keeping historical data intact and untouched.
Conclusion
Archiving an ActivityInfo database is a combination of access control, data protection, and clear communication.
By following these steps, you can create a reliable, read-only archive that continues to support analysis and reporting without risking unintended changes. This structured approach ensures that your data remains accessible, trustworthy, and aligned with organizational data management practices long after active data collection has ended.