Move information with a clear purpose and a way to prove it works
A new system is only useful if people can trust the information in it. Stratiis helps organisations plan what data and records will move, how they will be checked, who can access them and what happens to the old system after launch.
What is data and records planning for a new system?
It is the work of identifying existing information, deciding what the new system needs, preparing a migration or integration method and checking the result. It also sets ownership, access, retention and support responsibilities for records that remain in the old system or move into the new one.
Make the new platform dependable from launch
Data quality and record decisions affect every workflow that depends on the system.
Trusted records
Users can find the right, current information.
Fewer surprises
Missing fields and duplicates are discovered before cutover.
Clear ownership
Business owners approve what moves and what stays.
Useful evidence
Test results show whether the move meets agreed criteria.
What should a data and records plan include?
The scope depends on the source systems, type of records and risk of the change. These decisions make the work testable.
| Area | What to establish | Useful output |
|---|---|---|
| Sources and owners | Where information lives and who can approve decisions about it. | Source inventory and named owners. |
| Scope | Which records are needed in the new system, kept elsewhere or excluded. | Agreed migration and archive scope. |
| Quality | Duplicates, incomplete fields, inconsistent formats and outdated records. | Cleansing actions and acceptance rules. |
| Mapping | How source fields, identifiers and relationships fit the new structure. | Field mapping and transformation rules. |
| Access and protection | Who can view, edit, export and administer each type of information. | Permission and handling requirements. |
| Transfer and timing | How data moves, when changes stop and how cutover is coordinated. | Migration runbook and fallback decisions. |
| Verification | How completeness, accuracy and usability will be checked. | Test evidence and business sign-off. |
| Old system | What remains available, who maintains it and when it can be retired. | Archive and decommissioning plan. |
Business owners should approve the meaning and quality of records. The technical team and software supplier can then agree the transfer method and checks.
Find the records and dependencies that matter most
Review real use cases before deciding that every historic record belongs in the new platform.
Current sources
Include spreadsheets, shared files, databases and information held by suppliers.
Process needs
Link each field and record to the task, decision or report it supports.
Permissions
Confirm who can see sensitive information in both old and new systems.
Connected systems
Identify integrations, exports and reports that depend on record structure.
Protection and recovery
Agree the supplier and internal responsibilities for protecting and recovering information.
Ongoing ownership
Define who fixes data errors, approves changes and keeps records useful after launch.
From inventory to an accepted set of records
Each stage should produce a decision or test result that the business can review.
Discover
List sources, owners, uses, quality issues and constraints.
Prepare
Agree scope, cleanse records, map fields and define access.
Test
Move a representative sample and check key tasks and reports.
Handover
Confirm acceptance, old-system access and support ownership.
New System Deployments coordinates this work with configuration, user testing, launch and support.
Give business decisions to the people who know the records
Technology can transfer data, but its meaning, use and acceptance need business ownership.
Before migration
Assign owners for each source and define which information is current, required, sensitive or subject to an existing retention policy. Agree who can approve exclusions and corrections.
During delivery
Record field mappings, exceptions and test outcomes. Ask representative users to verify that records support real tasks, then document who handles errors after go-live.
IT Project Management can coordinate owners, supplier dependencies and sign-off.
How do you confirm the data move worked?
Check more than the number of records transferred. The information also has to be accurate, connected and usable.
| Test | What it confirms |
|---|---|
| Completeness | Required records and fields are present, with omissions investigated. |
| Accuracy | Values, dates, formats and key identifiers match agreed rules. |
| Relationships | Linked people, cases, assets or transactions stay connected. |
| Permissions | Users can access only the records and actions intended for their role. |
| Everyday tasks | Search, updates, reports and key workflows work with migrated records. |
| Exceptions | Rejected or unusual records are visible and have an owner. |
| Cutover | Changes made near launch are captured and reconciled as planned. |
Agree acceptance criteria before the test move. Business owners should review samples and sign off against those criteria.
Plan what happens to the old information
Some records move; others remain available for a defined reason. Document the decision rather than leaving an old system in indefinite use.
Keep
Identify records still needed for live work.
Archive
Set a practical route to access retained records.
Protect
Apply appropriate access and recovery arrangements.
Retire
Agree when old access and systems can be closed.
Retention and deletion decisions should follow your organisation's policies and applicable obligations. Technology Roadmaps can place decommissioning alongside future system changes.
Connect data readiness to the wider deployment
Good records depend on sound processes, access and ongoing system support.
New System Deployments
Coordinate the platform, data, users and launch.
Business Process
Map the work the new information must support.
Identity and Access
Control who can use and change each record.
Microsoft 365 Services
Plan connected workplace information and collaboration.
Data and records for new systems explained
What is data migration in a system deployment?
Data migration is the planned transfer of information from a source into a new system. It includes selecting records, mapping fields, moving data and verifying that the result is complete and usable.
Should we move every historic record?
Not automatically. Decide what is needed for current work, reporting or an existing retention requirement. Records that do not belong in the new system may need a separate archive or disposal decision.
Who is responsible for data quality?
The business owner should define what accurate, usable data means and approve corrections. IT and the supplier can support extraction, transformation and technical checks.
What is a data mapping document?
It records how fields and relationships in a source system correspond to those in the new system, including transformations, defaults and exceptions.
How should we test a data migration?
Use a representative sample, compare key values and counts, test relationships and ask users to complete real tasks. Record issues and repeat the test after fixes.
What happens to the old system after launch?
Agree whether it stays available for reference, how access is controlled, who supports it and when it can be retired. Document how retained records will be found.
How do we protect sensitive records during a move?
Identify sensitive information, agree who may handle it, restrict access and use an approved transfer and storage method. Test the permissions in the new system before launch.
Can Stratiis work with our software supplier?
Yes. Stratiis can coordinate data dependencies, access, testing and handover with the supplier. The parties should agree who performs product-specific extraction, transformation and import.
Make the information in your new system ready for real work
Tell us what system you are changing and where records, data quality or migration responsibilities need a clearer plan.
