Migrating From LTI® 1.1 to LTI® 1.3
Worth having open while you plan: 1EdTech's security deprecation schedule, which sets out what is being retired, and its guidance on selecting a user ID, which is the part of a migration that most often goes wrong.
An existing LTI® 1.1 integration keeps working for as long as the platforms you support keep accepting it. There is no cutoff date. What there is instead is a slow narrowing: 1EdTech deprecated 1.1 in 2022 and no longer certifies it, it gains no new services, and each platform decides on its own when to stop.
The work divides into three parts, and only the first is code.
What actually changes
Almost all of it. The full comparison covers the detail; the parts that force code changes are:
| You had | You now need |
|---|---|
| A shared secret per institution | A key pair, and a published key set |
| OAuth 1.0a signature verification | ID Token JWT verification |
| One endpoint receiving a signed form post | A login initiation endpoint and a launch endpoint |
Form fields (lis_person_name_full) | Namespaced claims in a JWT |
| Basic Outcomes for a single score | Assignment and Grade Services |
Role strings (Instructor) | Role URIs, scoped by system, institution and context |
What does not change is your product. The launch still arrives, still identifies a user and a course, and still lands them somewhere in your application. Everything downstream of "who is this and what are they opening" stays as it is.
The part that bites: user identity
This is the one thing that will silently break, and it is worth planning before you write anything.
Under 1.1 you most likely identified a user by user_id, scoped by
oauth_consumer_key or tool_consumer_instance_guid. Under 1.3 you identify
them by the sub claim, scoped by the platform issuer.
These are not guaranteed to be the same value. Some platforms send the same underlying identifier in both; others do not. If you switch a live integration without accounting for it, returning users arrive looking like strangers: new accounts, no history, lost progress.
Handle it explicitly:
- Before migrating, make sure you are storing the 1.1 identifiers you have, not just your own internal user ID.
- During the transition, when a 1.3 launch arrives for an institution that also has a 1.1 registration, try the 1.3 identity first and fall back to matching the legacy one.
- When a legacy match succeeds, write the new identifier onto the existing account so the fallback is used once per user rather than forever.
- Keep the fallback until the 1.1 registration for that institution is gone.
Matching on email address instead is tempting and a bad idea. Some platforms send no email at all, addresses change, and two accounts can share one.
The part that takes longest: re-registration
A 1.3 registration is a new registration. Every institution using your tool has to add it in their admin console, which means the pace is set by other people's change windows and support queues.
Two things reduce the pain:
- Support dynamic registration. Where the platform offers it, an administrator pastes one URL and the systems exchange everything else. It removes the step where somebody copies a client ID by hand and introduces a typo.
- Run both versions in parallel. Keep the 1.1 registration working while 1.3 is added alongside it, so each institution moves when it is ready and nothing goes dark if a change window slips.
Running both is also possible on LTIAAS. 1.3 is the default, and LTI® 1.1 can be enabled on your account for the institutions that still need it, so the two can coexist during a migration rather than forcing a single cutover. Ask us if you need it.
A sequence that works
- Stand up 1.3 alongside 1.1. New endpoints, new code path, existing integration untouched.
- Add the identity fallback described above, before any real institution uses the new path.
- Migrate one friendly institution. Ideally one running a platform you know well, with someone who will tell you when something looks wrong.
- Verify with real users, specifically that returning users keep their history. This is the check that matters; a launch that merely succeeds proves less than it seems.
- Roll out, tracking which institutions have moved.
- Retire 1.1 per institution, once nothing has arrived on the old path for long enough to be confident.
Do not switch an institution over during their teaching term if you can avoid it. A failed launch in week one of a course is a different kind of incident from a failed launch in August.
Doing it without implementing 1.3
The migration is a good moment to ask whether you want to own the protocol at all. You are rewriting the integration either way; the choice is whether the new version is yours to maintain.
With LTIAAS the 1.3 side is a redirect and an API call — adding LTI® to your application shows the shape — and the per-platform differences you are about to meet for the second time are handled for you.
If you are keeping it in house, the 1EdTech specification is the authority, and what is LTI® 1.3 walks the sequence you will be implementing.
Common questions
Do I have to migrate from LTI® 1.1?
Not immediately. 1EdTech deprecated 1.1 in 2022 and no longer certifies it, but platforms decide their own timetables and several still accept it. The position shrinks over time rather than ending on a date.
Will my existing users be recognised after migrating?
Only if you plan for it. LTI® 1.1 and 1.3 identify users differently, so unless you map the old identifier to the new one during the transition, a returning user can arrive looking like a new account.
Can I run LTI® 1.1 and 1.3 at the same time?
Yes, and during a migration you generally should, so an institution can move when it is ready rather than on your schedule. LTIAAS can run both for you, which avoids maintaining a second implementation for the duration.
Does migrating mean re-registering with every institution?
Yes. A 1.3 registration is a new registration with new values, so every institution using your tool has to add it. That coordination is usually the longest part of the work.
Next
- LTI® 1.3 vs LTI® 1.1 — the full comparison
- How to add LTI® 1.3 to your application
- Manual LMS registration — registering by hand
