- Configuration
- Migration
- Validation
- Permissions
- Reconciliation
- Controlled Rollout
- Product Assurance
School Profile
Maintain the organisation’s core identity and settings.
Academic Structure
Configure relevant phases, year groups, classes and subjects.
Terms and Timetable Context
Establish appropriate operating periods and teaching structures.
Staff
Connect the people working within the school.
Roles
Define responsibilities.
Permissions
Determine what each role should be able to access.
Learners
Establish the core learner population.
Family Relationships
Connect appropriate parents and carers.
Enabled Workflows
Introduce the parts of EdiWay relevant to the school’s implementation.
The aim is to model the organisation accurately before asking staff to depend on connected workflows.
Foundation
School structure, users, learner records and permissions.
Everyday Operations
Classes, timetable, attendance and communication.
Teaching and Learning
Teacher workspace, resources, assignments and assessment.
Learner Support
SEND, wellbeing, medical and safeguarding workflows.
Leadership
Reporting, compliance, governance and school improvement.
Families
Parent, carer and learner experiences.
Professional Collaboration
Purpose-scoped external relationships where enabled.
Advanced Workflows
Introduce additional capabilities only when configuration, assurance and organisational readiness support them.
This helps implementation reflect the school’s priorities rather than becoming a race to activate every feature.
School Settings
Define relevant organisational information.
Roles and Responsibilities
Establish staff access around actual responsibilities.
Custom Fields
Add appropriate organisation-specific information where supported.
Workflow Settings
Configure available behaviour within supported boundaries.
Feature Availability
Enable appropriate platform areas.
Notifications
Configure relevant communication behaviour where available.
Review Requirements
Set suitable ownership or review context.
Permissions
Control who can view or change the configured information.
Configuration should adapt supported workflows. It should not be presented as an unrestricted no-code system capable of safely rebuilding any process the school can imagine.
Staff Roles
Who requires access to each platform area?
Learner Relationships
Which learners fall within that person’s responsibility?
Sensitive Domains
Who can access SEND, safeguarding, medical, wellbeing or HR information?
Family Access
Which parents and carers are connected to each learner?
Professional Access
Which external relationships are authorised?
Temporary Access
When should permissions expire?
- Learner identifiers
- Staff identifiers
- Class structures
- Attendance codes
- Parent and carer relationships
- Historical records
- Status values
- Custom fields
- Duplicates
- Missing information
- Attachments
- Dates and timestamps
A migration plan should therefore distinguish between:
Available Source Data
What can actually be exported from the current system?
Required EdiWay Data
What is needed for the intended workflows?
Mappable Data
Which source fields have an appropriate destination?
Data Requiring Review
Which information cannot safely be interpreted automatically?
Historical Data
How much history needs to be retained?
Unsupported Detail
Which source information cannot currently be reproduced with equivalent fidelity?
Migration should make those differences visible rather than quietly inventing mappings.
Learners
Import appropriate core learner information.
Staff
Bring suitable workforce identity information into the school context.
Classes
Connect supported class information.
Attendance
Import appropriate attendance data through supported mappings.
Parent Fields
Bring suitable family-related information into the learner structure.
Validation
Check imported data before or during processing.
Batch Processing
Handle supported imports through controlled batches.
Result Tracking
Keep successful and failed row outcomes understandable.
The exact migration scope depends on the source system, available export and current supported mappings.
Data Validation
Check supported information against expected structures.
Duplicate Detection
Identify possible duplicate records.
Missing Information
Make incomplete data easier to identify.
Source Mapping
Connect imported identifiers to appropriate EdiWay records.
Row Outcomes
Understand which records succeeded or failed.
Errors
Preserve appropriate migration-error context.
Reconciliation
Compare migration results with the intended source population.
Review
Require human attention where mappings or outcomes are uncertain.
A successful technical import should not automatically be treated as evidence that every field is accurate.
Source Records
How many records were supplied?
Accepted Records
How many were successfully processed?
Rejected Records
Which entries require correction?
Source IDs
Can imported records be related back to their source identity?
Target IDs
Which EdiWay records were created or updated?
Errors
Why did individual rows fail?
Repeated Runs
Can processing continue safely after an interrupted or failed batch?
Final Review
Does the resulting school population make sense?
Migration assurance should focus on evidence rather than simply reporting that an import job “completed”.
Older systems may contain:
- Previous schools
- Historic attendance
- Behaviour history
- Assessments
- SEND records
- Safeguarding history
- Status changes
- Attachments
- Original authors
- Original timestamps
- Legacy identifiers
Export Format
What can the existing provider supply?
Field Definitions
What does each field actually mean?
Identifiers
How are learners, staff and relationships represented?
Code Mapping
How should source values translate?
Historical Depth
What history can be preserved?
Attachments
Can supporting files be migrated appropriately?
Exceptions
Which records require manual review?
Validation
How will the finished migration be reconciled?
Specific migration capability should be confirmed against the actual source system rather than assumed from a supplier name alone.
Source System
Which system supplied the data?
Source File
Which migration input contained the record?
File Fingerprint
Identify the relevant source artefact.
Row Identity
Keep appropriate input-row context.
Source Learner ID
Relate the learner back to the originating system where supported.
EdiWay Record
Identify the resulting target record.
Error State
Preserve information where processing failed.
This helps migration remain an auditable process rather than becoming an unexplained transformation of school data.
Duplicate Learners
Potential duplicate identities.
Missing Contacts
Incomplete parent or carer information.
Invalid Relationships
Relationships requiring school review.
Missing Fields
Information expected by a new workflow but absent from the source.
Historic Codes
Values that no longer match the current school configuration.
Conflicting Information
Different records giving different versions of the same fact.
Incomplete History
Source data that cannot support the intended historical view.
These should become review items. EdiWay should not silently infer missing sensitive information merely to make a migration appear complete.
Installation and Migration
Does the workflow operate correctly on the intended environment?
Permissions
Do authorised roles succeed?
Denial
Are unauthorised roles blocked?Identify the relevant source artefact.
School Isolation
Does information remain within the correct organisation?
Concurrency
What happens when more than one person acts at the same time?
Failure and Recovery
What happens when an operation does not complete normally?
Data Reconciliation
Does the resulting record match the expected source?
Accessibility
Can the workflow be used appropriately across supported experiences?
Rendering
Do documents and reports produce the intended result?
Security
Have the relevant security controls been sufficiently assured?
Implementation should consider these questions according to the risk and purpose of the workflow.
Defined Participants
Limit initial use to appropriate schools or users.
Defined Workflow
Test a specific capability rather than opening an entire domain.
Known Boundaries
Make limitations visible.
Feedback
Understand how the workflow performs in real school practice.
Issue Review
Identify failures or confusing behaviour.
Permission Testing
Check different authorised and denied roles.
Reconciliation
Confirm resulting records remain accurate.
Expansion
Increase use when the evidence supports it.
Controlled rollout is not a weakness to hide. For higher-consequence education workflows, it is part of responsible product development.
Product Foundations
Core records or services exist.
Integrated Workflow
The capability operates across connected platform components.
Static Evidence
Implementation has been verified through code-level review.
Runtime Testing
The workflow still requires broader operating evidence.
Controlled Rollout
Use is limited while assurance continues.
Release Assurance
The relevant production criteria have been sufficiently satisfied for the intended scope.
A feature appearing within the platform architecture should not automatically be interpreted as meaning every variation of that feature is production-ready.
Reliable systems should distinguish between:
- Zero results
- No available data
- Missing configuration
- Unsupported workflows
- Failed operations
- Permission denial
- Incomplete migrations
- Features still undergoing assurance
Schools change:
- Staff
- Learners
- Classes
- Timetables
- Policies
- Providers
- Permissions
- Data
- Workflows
Data Structures
New information or relationships.
Permissions
New roles or actions.
Workflows
New stages or behaviours.
Reports
New data and presentation requirements.
AI
New governed assistance capabilities.
Integrations
New external dependencies.
Configuration
New school options.
Migration
Changes needed for existing installations. Release control and migration checks help distinguish product development from production assurance.
A newer capability should not bypass the testing required for its intended use simply because the surrounding platform is already in use.
EdiWay should not currently make blanket claims of:
- One-click migration from every MIS
- Complete historical migration from every source
- Automatic preservation of every legacy attachment
- Perfect conversion of every vendor-specific field
- Zero implementation work
- Instant activation of every platform workflow
- Production readiness based solely on code completion
- Universal external-system integration
- Automatic legal or statutory configuration
- Independent security certification where it has not been completed
- Error-free migration without reconciliation
- Fully assured access for every possible role combination without testing
A more useful promise is: We will make the implementation scope, migration evidence and remaining assurance boundaries visible.
1. Define the Intended Scope
Identify the EdiWay workflows the school plans to use.
2. Model the School
Configure the organisational and academic structure.
3. Establish Roles and Permissions
Define who should – and should not – access each area.
4. Review Source Data
Understand exports, mappings, history and known limitations.
5. Migrate Supported Data
Import the records included within the agreed migration scope.
6. Validate and Reconcile
Review successful records, failures, duplicates, gaps and source mappings.
7. Configure Workflows
Set up the relevant available school processes.
8. Test Roles
Check expected access and important denial scenarios.
9. Review Higher-Risk Areas
Apply additional assurance to sensitive workflows.
10. Begin Controlled Use
Introduce the agreed platform areas.
11. Review Real-World Behaviour
Capture issues, data-quality gaps and user feedback.
12. Expand Deliberately
Introduce additional workflows when implementation and assurance support them.
Yes.
EdiWay has governed data-import foundations and migration tooling for supported school data.
The exact migration scope depends on the source system and current supported mappings.
The current migration foundation includes canonical mappings around learner, staff, class, attendance and parent-related fields.
Specific fields and source formats need to be assessed for the intended migration.
A universal complete migration from every MIS should not currently be assumed.
Vendor-specific specifications and mappings require verification.
Supported imports can automate parts of data processing, but migration still requires mapping, validation, reconciliation and human review.
Migration workflows can retain row outcomes and errors, supporting review of records that did not process successfully.
Data-validation capabilities include duplicate detection and missing-data awareness within the wider platform scope.
Historical-data migration is supported in part, but complete legacy fidelity should not be assumed.
Some original actors, timestamps, attachments and complete status histories may not currently be preserved through every migration path.
Sensitive historical migration should only be undertaken through an appropriate, specifically assured migration scope.
General core-data migration capability should not be interpreted as proof that every safeguarding-history scenario is ready.
Migration should be validated and reconciled before operational dependence.
The current internal roadmap still identifies fuller dry-run field mapping and recovery/rollback assurance as areas requiring further work.
Configuration and custom-field capabilities are represented.
A completely unrestricted school-facing workflow builder should not currently be assumed.
Yes.
The platform can be approached through staged implementation, with relevant workflows introduced according to school priorities, configuration and current availability.
It means a capability is available within a bounded implementation or testing context while additional runtime evidence and assurance are still being gathered.
Not necessarily.
EdiWay’s internal capability catalogue explicitly distinguishes capability coverage from release assurance.
Implementation should consider both authorised access and denial scenarios.
Some all-role and cross-school runtime assurance remains part of ongoing product testing.
Security assurance is an ongoing product requirement.
The current internal assurance record identifies independent security testing as an area that should not be presented as complete without the corresponding evidence.
No.
Complex data migration requires validation and reconciliation.
The responsible approach is to expose and resolve exceptions rather than promise that they cannot occur.
Unsupported or ambiguous information should be identified for review rather than silently assigned to an inaccurate destination.
No.
AI capabilities remain governed by availability, entitlement, permissions and workflow-specific assurance.
No.
An integration should only be represented as available when the specific connection has been implemented, tested and documented.
Readiness depends on the workflow and its consequences.
Relevant assurance may include installation, migration, permissions, denial, isolation, concurrency, recovery, accessibility, rendering, reconciliation and security evidence.
Permissions, Consent and Information Sharing
Establish the access relationships required before wider rollout.
Data Security and Governance
Understand the broader security, access and platform-governance approach.
Privacy and Data Protection
Connect migration and implementation to appropriate privacy responsibilities.
Data Retention and Subject Rights
Understand how retained and migrated personal information connects to lifecycle obligations.
AI Governance
Understand the additional controls around governed AI workflows.
School Setup and Leadership
Model the organisation, roles and school structure that connected workflows depend on.