The Complete Access to Power Platform Migration Checklist

Migrating from Microsoft Access to the Power Platform is a significant undertaking. Done well, it modernizes your data infrastructure, improves accessibility, and sets you up for years of growth. Done poorly, it disrupts operations and erodes user trust. This checklist covers every phase of a successful migration.

Phase 1: Assessment and Planning

Inventory Your Current Database

• Document all tables and their row counts
• Document all queries (SELECT, action, crosstab, union)
• Document all forms and their complexity (simple data entry vs. complex with VBA)
• Document all reports and their output formats
• Document all macros and VBA modules
• Identify all external data connections (linked tables, ODBC sources)
• Identify all integrations (Excel exports, email automation, file operations)

Assess Complexity

• Categorize each object as Simple, Medium, or Complex
• Identify VBA code that has no Power Platform equivalent
• Identify Access-specific features (OLE objects, complex crosstab queries)
• Estimate rebuild effort for each major component

Choose Your Target Platform

• SQL Server + Access frontend — minimal disruption, maximum compatibility
• SQL Server + Power Apps — modern UI, requires app rebuild
• SharePoint + Power Apps — cloud-first, good for simple data
• Dataverse + Power Apps — full Power Platform, highest capability and cost
• Azure SQL + Power Apps — cloud SQL Server, best for scale

Define Success Criteria

• Which users will be affected?
• What is the acceptable downtime during cutover?
• What functionality must be preserved exactly?
• What functionality can be simplified or eliminated?
• What is the rollback plan if migration fails?

Phase 2: Data Migration

Prepare the Source Data

• Compact and repair the Access database
• Identify and resolve data quality issues (nulls in required fields, invalid foreign keys)
• Document all table relationships and referential integrity rules
• Identify fields with Access-specific data types (OLE Object, Attachment)
• Plan how to handle OLE Object and Attachment fields

Migrate Tables

• Create the target database (SQL Server, Dataverse, SharePoint)
• Map Access data types to target data types
• Create tables in the target system
• Migrate data using the appropriate tool:
  • SQL Server: Access Upsizing Wizard or SSMA (SQL Server Migration Assistant)
  • SharePoint: Access "Move to SharePoint" wizard
  • Dataverse: Data Import Wizard
• Verify row counts match between source and target
• Verify data integrity (no truncation, no type conversion errors)
• Recreate indexes and relationships in the target system

Validate Data

• Run spot checks on migrated data
• Compare aggregate values (totals, counts) between Access and target
• Test all foreign key relationships
• Verify date and numeric field precision

Phase 3: Application Rebuild

Rebuild Queries

• Convert SELECT queries to SQL Server views or stored procedures
• Convert action queries to stored procedures
• Test all converted queries against migrated data
• Document any queries that required significant rewriting

Rebuild Forms (as Power Apps)

• Start with the most-used forms
• Implement data entry forms as canvas apps
• Implement navigation and main menu
• Implement validation rules
• Implement cascading dropdowns
• Test with real users before proceeding

Rebuild Reports (as Power BI)

• Connect Power BI to the target data source
• Rebuild key reports as Power BI reports
• Implement scheduled refresh
• Publish to Power BI Service
• Share with appropriate users

Rebuild Automation (as Power Automate)

• Document all Access macros and VBA automation
• Rebuild email notifications as Power Automate flows
• Rebuild scheduled tasks as scheduled flows
• Rebuild approval workflows using Power Automate Approvals
• Test all flows end-to-end

Phase 4: Testing

Functional Testing

• Test every form against every use case
• Test every report for accuracy
• Test all automation flows
• Test error handling and edge cases
• Test with realistic data volumes

User Acceptance Testing

• Identify key users for UAT
• Provide training on the new system
• Document all issues found during UAT
• Resolve critical issues before go-live
• Get sign-off from key stakeholders

Performance Testing

• Test with the expected number of concurrent users
• Verify query performance meets requirements
• Test report generation times
• Identify and resolve performance bottlenecks

Phase 5: Go-Live

Pre-Cutover

• Final data migration from Access to target (or plan for live cutover)
• Verify all users have access to the new system
• Verify all users have been trained
• Prepare rollback plan
• Schedule cutover during low-usage period

Cutover

• Notify all users of the cutover
• Lock the Access database (prevent new data entry)
• Run final data migration
• Verify data integrity post-migration
• Switch users to the new system
• Monitor for issues in the first hours

Post-Go-Live

• Keep the Access database available read-only for reference (30-90 days)
• Monitor error logs and user feedback
• Address issues promptly
• Plan for decommissioning the Access database

Phase 6: Post-Migration

• Document the new system architecture
• Train remaining users
• Establish ongoing maintenance procedures
• Plan for future enhancements
• Decommission the Access database after the retention period

When to Consider Staying with Access

Not every Access database needs to migrate. Consider staying with Access when:

• The database serves a small team (under 10 users) with no plans to grow
• The VBA logic is too complex to rebuild economically
• Users are not ready for the learning curve of Power Apps
• The cost of migration exceeds the benefit

A well-maintained Access database with a SQL Server backend can serve a team reliably for many years. Migration should be driven by genuine business need, not technology trends.

Conclusion

A successful migration is built on thorough assessment, careful data migration, incremental application rebuilding, and rigorous testing. Use this checklist as your guide, involve key users throughout the process, and maintain a rollback plan until you are confident the new system is stable. The result — a modern, cloud-accessible, mobile-friendly application — is worth the investment when done right.