Changing the software that runs your projects is a big decision, and most of the attention goes to features, price and training. Less attention goes to the security and data side of the move: what happens to years of records, who has access during the transition, and what is left behind in the old system when you stop paying for it.
Whether you are moving between project management platforms, changing document systems or adopting a new construction accounting package, this checklist helps you manage the data side responsibly.
Before you choose: security questions
Add a few questions to your vendor evaluation:
- Does the platform support multifactor authentication and single sign-on?
- Can administrators control permissions at a granular level, by project and role?
- What audit logs are available, and for how long?
- How are data encrypted in transit and at rest?
- Where is data stored, and what backup and recovery options exist?
- Can you export all your data in usable formats, and does the vendor support that on request?
- What does the contract say about data ownership, deletion on termination and incident notification?
A platform that makes it hard to leave is a platform that creates risk later.
Phase 1: Plan the cutover
- Name an owner for the migration, plus a security and data contact.
- Define scope. What data moves, what is archived and what is deleted?
- Choose a timeline that avoids busy periods such as year-end close, payroll peaks or major project milestones.
- Decide on a pilot project to test the new system before moving everyone.
- Check regulatory and contractual retention. Some records must be kept for years, and some contracts restrict where certain data may be stored.
Phase 2: Prepare the data
- Inventory what lives in the old system: drawings, RFIs, submittals, contracts, financials, photos, daily logs
- Identify sensitive items, such as personnel data, banking details and any controlled information
- Clean up duplicates, outdated files and users who no longer need access
- Export a complete backup of the old system and store it securely before changes begin
- Confirm the export includes metadata, such as dates, authors and approvals, if you need it for records
Phase 3: Set up the new environment securely
- Configure single sign-on and multifactor authentication before inviting users
- Build permission templates by role, rather than copying legacy access wholesale
- Set up the project structure and naming conventions
- Review default settings, such as public sharing, and turn off what you do not need
- Limit administrator accounts to a small number of named people
- Connect integrations deliberately, with minimal permissions
Resist the temptation to replicate the old system's access list. Migrations are a rare chance to start with least privilege.
Phase 4: Migrate and verify
Move data in stages, beginning with a pilot. After each stage:
- Compare record counts and sample documents between old and new
- Verify that permissions match intent
- Test search, reporting and approval workflows
- Have end users confirm that what they need is present and usable
Keep notes on exceptions and corrections.
Phase 5: Train and communicate
Give users concise training on the new tools and on security rules, such as how to share externally and how to report problems. Tell outside partners, such as subcontractors and owners, how access will change and when, using official channels. Warn staff that criminals sometimes exploit transitions with fake invitation emails, so users should only accept invites that come through the verified process.
Phase 6: Run in parallel briefly, then retire the old system
A short overlap lets you catch missing information. Set a firm date for the old system to become read-only, then retire it. Do not leave it running indefinitely unmonitored.
Phase 7: Decommission carefully
Many organizations skip this phase, and it is where the lingering risk remains.
- Confirm the final export and verify it can be opened
- Revoke all user access and integrations
- Remove single sign-on connections and tokens
- Request written confirmation of data deletion from the vendor, consistent with your retention needs
- Cancel billing and update your system inventory
- Remove stored credentials and integrations from other platforms that pointed to the old system
Common mistakes
- Migrating without a verified backup
- Inviting external users before permissions are tested
- Copying obsolete accounts into the new system
- Leaving the old platform active after the cutover
- Forgetting integrations that still send data to the old tool
After the cutover
Hold a review after 30 and 90 days. Check adoption, support requests, permission issues and any security alerts. Update documentation and policies to match.
How Ironfield Cyber helps
Ironfield Cyber supports contractors and energy companies through software transitions, including security configuration, data export planning and access design. If you are weighing a platform change, we can help you plan the data and security side before the first file moves.