Journey implementation planning
Move the workflow with the record.
A platform change succeeds when people can complete their work with the records they need. Use this planning guide to prepare a Journey evaluation, agree the implementation boundary and decide what must be proven before a cutover.
Published product · edition and implementation scope confirmed during evaluation
The product website describes Journey today. Website demonstrations use illustrative records; confirm the required edition, configuration and supported workflow in a current walkthrough.
UK-hosted, GDPR-compliant
Illustrative workflow
Follow the work through Journey.
Prepare
Agree the source snapshot, selected records, field mapping, authorised environment and responsible people.
Choose a useful first scope
Start with a workflow you can accept.
Name the first operational result: for example, a tutor can prepare and record a review for an agreed cohort using the right learner and programme context. Then identify the minimum records, documents, users and permissions that result needs.
Do not assume every historic file should move into an active workspace. Distinguish current operating records, historical material that must remain accessible, duplicates, missing information and material that should be excluded. Confirm responsibilities and retention requirements with your own organisation.
- Which learners and programmes are in the first scope?
- Which dates, statuses and identifiers must remain recognisable?
- Which documents must stay linked to their source and version?
- Who owns data quality, configuration and the acceptance decision?
Before an import is agreed
Map meaning as well as columns.
A field labelled complete in one system may mean something different in another. Document the meaning of status values, dates, owners, reviews and evidence links before treating a matching column name as a matching record.
Journey’s public product information describes imports and exports, while the repository records boundaries around particular import workflows. Confirm the exact source, file type, record family and supported migration route for your project. A supported applicant import should not be treated as evidence that every historical funding or evidence record can be migrated automatically.
| Decision | Evidence to retain |
|---|---|
| Source and ownership | Named source system, data owner and authorised export. |
| Mapping | Field meanings, required values and status conversions. |
| Exceptions | Rejected or ambiguous records with an owner and reason. |
| Acceptance | Agreed record counts, relationships and representative checks. |
Prove the transition
Rehearse a small, representative set.
Use a bounded rehearsal with representative complexity: an active learner, a learner on a break, a changed plan and an evidence item that must stay connected. Avoid putting personal records into an unapproved evaluation environment.
Check more than row counts. Inspect programme relationships, evidence links, permissions, dates, review history and the outputs your teams rely on. A successful import message is not an acceptance decision.
Prepare
Agree the source snapshot, selected records, field mapping, authorised environment and responsible people.
Rehearse
Use the supported route and retain the exceptions rather than filling missing values with guesses.
Reconcile
Compare counts and representative records; check the relationships that make the workflow usable.
Exercise the work
Ask the intended roles to complete the review, evidence or readiness task in the agreed scope.
Decide
Record accepted items, outstanding gaps, recovery arrangements and the person who can authorise the next stage.
The operating plan
Agree what happens during the change.
Choose a change window around your provider’s real delivery and reporting commitments. Record when the old source is frozen or remains authoritative, where new work is recorded and how any interim changes are reconciled.
Confirm role onboarding, support routes, required exports and recovery arrangements in writing. If the first scope depends on another supplier, include that supplier’s owner and acceptance evidence. A calendar date alone should not override an unresolved data or access problem.
Before commitment
Confirm the edition and service boundary.
Ask which edition supports the required capabilities, which implementation work is included and what the provider must supply. Confirm migration assistance, configuration, training, ongoing support and any external connection separately.
Use Journey’s current written proposal and edition information as the commercial authority. This guide is a preparation method; it does not promise automatic migration, a fixed implementation time or compatibility with an unnamed supplier.
Questions before the next step
A clearer view of Journey.
Can Journey import everything from our current platform?
That must be confirmed against your source system, record types and the currently supported migration route. Supply a minimised sample specification and agree a rehearsal before relying on an import promise.
Who should own rollout acceptance?
Name a business owner who can accept the operating result, supported by the people responsible for delivery, data, access and any affected funding or quality work. Technical completion alone is not operating acceptance.
What should remain available after cutover?
Agree access to necessary history, exports, unresolved exceptions and recovery information. Your organisation decides its obligations and operating needs; the implementation plan should make them explicit.
Make the next conversation useful
Start with the work.
Explore the fit.
Bring your workflow, the people involved and the decisions you need to make.