Why migrations stall — and how to avoid it
Most proctoring migrations fail not because the new tool is worse, but because the migration was under-planned. The LMS integration breaks. Faculty weren't consulted. The IT security review runs parallel to, not ahead of, the rollout. Suddenly it's semester week and nobody's confident the exams will run.
This guide is built from real migration patterns — the ones that go smoothly and the ones that don't. Use it as your working document from the moment you start evaluating ProctorSafe.
Phase 1: Pre-evaluation (4–6 weeks before decision)
Stakeholder alignment
Before you evaluate any tool, align internally on what you're actually solving:
- Define the primary pain point. Is it student privacy complaints? GDPR non-compliance risk? IT security concerns? Cost? All of the above? Write it down — it determines which criteria matter most in evaluation.
- Identify your decision-makers. Typically: LMS administrator, Information Security, Legal/Compliance (or DPO), Faculty representative, Student rep (if available).
- Set a decision deadline. Proctoring decisions that don't have a hard deadline tend to drift past one academic term.
- Agree on the evaluation criteria. Rank them: privacy compliance, LMS integration depth, faculty experience, student experience, cost, support SLA.
Technical prerequisites
- Identify your LMS version (Canvas, Moodle, Blackboard) and hosting model (cloud-hosted, self-hosted, on-premise)
- Check LTI 1.3 / LTI Advantage support — ProctorSafe requires LTI 1.3
- Identify your identity provider (SSO) — ProctorSafe supports SAML 2.0 and OIDC
- Map your current proctoring data flows: what data leaves your institution, where does it go, how long is it retained?
Phase 2: Procurement and legal (2–4 weeks)
Security and compliance review
- Request a Data Processing Agreement (DPA) — this is mandatory under GDPR if you're a EU institution
- Request a Data Protection Impact Assessment (DPIA) template or ask the vendor to complete one for your use case
- Verify data hosting location — confirm EU data residency if required (ProctorSafe: EU-hosted)
- Check sub-processor list — who else touches the data, and under what constraints?
- Request penetration test results or SOC 2 report if available
- Confirm the vendor's incident response SLA — how quickly do they notify you if something goes wrong?
Contract review checkpoints
- Data retention period — how long does the vendor keep any data after the exam?
- Right to erasure — can you request deletion of all data associated with a student or cohort?
- Contract termination — what happens to your data when the contract ends?
- Acceptable use — are they using any data for AI model training or product improvement?
- Indemnification — who is liable if a data breach occurs at the vendor side?
Phase 3: Technical setup (2–4 weeks before pilot)
LMS integration
- Create a staging environment in your LMS — do not run the pilot in production
- Install the ProctorSafe LTI 1.3 app following the integration guide — the LMS-native approach requires no plugins
- Configure LTI Advantage claims — map the correct roles (learner, instructor, admin) to your LMS roles
- Set up roster sync — ensure student enrollments are passed to ProctorSafe correctly via LTI
- Configure SSO / SAML — link ProctorSafe to your institution's identity provider
- Test in staging: create a dummy exam, launch it, complete a session, verify the alert log appears in the instructor dashboard
ProctorSafe configuration
- Set your institution profile: name, logo, DPO contact, data retention period
- Define alert thresholds — decide what events trigger a review flag vs. auto-dismiss
- Configure reviewer accounts — who has access to the instructor dashboard? Do they need training?
- Set student notification settings — what does the student see before the exam? (ProctorSafe provides a standard privacy notice template)
- Test webhook delivery if you're integrating with your SIS or a custom dashboard
Phase 4: Pilot (1–2 exam cycles)
Before the pilot exam
- Brief faculty — walk them through the instructor dashboard, how to read alert logs, how to raise an appeal
- Brief students — send a clear, non-technical email explaining what ProctorSafe does and does not do. Include the student privacy guide. Do this at least one week before the exam.
- Prepare a fallback plan — if the proctoring fails, what's the contingency? (Typically: extend the window or allow a retake.) Agree this with faculty before exam day.
- Run a technical check — have students run the browser compatibility check 48 hours before the exam
During the pilot
- Monitor the instructor dashboard during the exam — watch the live alert feed
- Have a designated IT contact on standby in case of LMS or network issues
- Log any anomalies or issues for the post-pilot review
After the pilot
- Collect feedback from students — anonymous survey on their experience, privacy perception, technical ease
- Collect feedback from faculty — dashboard usability, alert quality, support responsiveness
- Review alert data — how many false positives? How many escalated to a human reviewer? This tells you whether your thresholds are calibrated correctly
- Document the pilot outcomes — this becomes your justification for full rollout
Phase 5: Full rollout (semester transition)
- Promote from staging to production in the LMS
- Update faculty onboarding documentation with ProctorSafe-specific instructions
- Set up semester-level data retention policy — define when alert logs are archived vs. deleted
- Schedule a quarterly review with the ProctorSafe team — bug reports, feature requests, upcoming LMS updates
- Set up a student FAQ page on your intranet — reference the student privacy guide
Common mistakes to avoid
| Mistake | Consequence | Prevention |
|---|---|---|
| Running pilot in production | Real student data, real risk | Staging-only for first cycle |
| No student communication before exam | Anxiety, complaints, escalations | Send privacy notice 1 week before |
| No faculty dashboard training | Low engagement, unused tool | 30-min walkthrough before pilot |
| Calibrating thresholds too aggressively | High false-positive rate, reviewer fatigue | Start conservative, tune after first cycle |
| Skipping the DPA | GDPR non-compliance | Get it signed before any data flows |
| No fallback plan | Exam disruption on technical failure | Agree contingencies before go-live |
Next steps
Ready to start the evaluation? Here's the recommended sequence:
- Request a technical walkthrough — live session with the ProctorSafe team to walk through the SDK, dashboard, and DPIA
- Get access to the staging environment — test the full integration before committing
- Request a sample DPA — have your legal team review it
- Set a decision deadline — put it in the calendar now
Assessment teams and LMS administrators: if you'd like a structured migration planning call with the ProctorSafe team, reach out at proctorsafe.eu/contact.