Migrating off Training Orchestra is less about moving files and more about moving a live operation. Most of the difficulty sits in three places: extracting data from a platform with no public developer portal, mapping a data model that splits training into Sessions and Sequences in a way most systems do not, and cutting over without disrupting courses that are already scheduled and already sold.
For a mid-sized training operation, a realistic timeline is eight to fourteen weeks from decision to go-live, with two to four of those weeks running both systems in parallel. Teams that try to compress it below six weeks usually do so by abandoning historical data, which is a choice worth making deliberately rather than by accident.
This guide covers what Training Orchestra holds, how to get it out, what typically will not come across, and how to sequence the switch around live delivery. It is written to be useful whether or not you end up choosing SimpliTrain. The export mechanics and the cutover sequence are the same regardless of where you land.
Should you actually leave Training Orchestra?
Worth asking honestly, because migration is expensive and disruption has a cost.
Training Orchestra is a training management system, not a learning management system. It was built to handle the logistics of instructor-led training: scheduling sessions, allocating trainers, booking rooms and tracking cost and budget. It is genuinely strong at that, particularly for large enterprise L&D functions running high volumes of classroom and virtual classroom delivery across multiple entities. If the distinction between the two categories is unfamiliar, our explainer on LMS versus TMS covers it in detail.
You probably should not move if your pain is mostly configuration rather than capability, you are inside the first eighteen months of an implementation that has not been fully adopted yet, or your complaint is that it does not deliver e-learning content, which it was never designed to do and which your LMS should be handling.
The reasons teams do move tend to cluster:
- You are a commercial training provider, not an internal L&D team. Training Orchestra’s design centre of gravity is corporate L&D. If you sell courses, you need a public catalogue, a checkout, invoicing, credit notes and a customer portal. Bolting those on around a TMS built for internal training is a recurring source of frustration, which is why we wrote separately about the best TMS for selling courses.
- You are paying for two systems. Because Training Orchestra deliberately sits alongside an LMS rather than replacing it, you fund both. Some teams reach a point where a unified learning platform covers their actual requirement at lower total cost.
- Reporting requires reconciliation. When scheduling lives in one system and delivery records in another, building a single view of training history means exporting from both and joining them by hand.
- Implementation and change costs. Public reviews of Training Orchestra are unusually scarce. As of writing there is roughly one review on G2 and none on Capterra, so there is very little peer signal to go on. An independent Talented Learning review describes a standard deployment as workshop-based and measured in months rather than weeks. Teams that need to reconfigure frequently find that friction expensive.
If two or more of those describe you, migration is worth costing out.
What Training Orchestra actually holds: the data model you are moving
This is the part most migration plans get wrong, because Training Orchestra’s structure does not map one-to-one onto most other systems.
The core hierarchy runs Course, then Session, then Sequence. A Course is the offering, the thing that exists in your catalogue. A Session is a delivery instance of that course, with its own status, cost lines and task list. A Sequence is a block of days within a session, and sessions can contain multiple sequences that run consecutively or with gaps between them.
That middle layer matters. A five-day programme delivered as three days in March and two in April is one Session with two Sequences in Training Orchestra. In a system that models a scheduled course as a single date range, that becomes either two separate courses, breaking the enrolment record, or one course with an invented end date, breaking the calendar. Deciding how to handle multi-sequence sessions is usually the single biggest mapping decision in the project, and it needs making before anyone touches an export.
Around that core sit:
- Trainees, learners and employees, with their organisational unit and entity assignments
- Instructors, trainers and SMEs, including skills, expertise areas, locations they can cover and billing rates
- Training providers, the external suppliers you buy delivery from
- Resources, meaning rooms, equipment, virtual classrooms, simulators and pre- and post-session materials
- Catalogue, the published course offering
- Cost and budget data, the module that most differentiates Training Orchestra and the data most often lost in migration
- Tasks, the workflow items attached to sessions
You may also have data inside the extension modules: Instructor Portal, Training as a Business, Client Collaboration and Training Regulation. Check which of these you licence before scoping, because each holds records the core export path may not cover.
One practical note if your instance was configured by a French-speaking implementation team or you are on a French-language tenant: you will see formation, stagiaire, organisme de formation and plan de développement des compétences in field names and exports. Build your mapping table against the field names in your own tenant, not the English marketing terminology.
Mapping Training Orchestra objects to a new system
Use this as a starting template. Populate the right-hand column with your target platform’s object names before you brief anyone on the extract.
| Training Orchestra object | What it represents | Migration difficulty |
|---|---|---|
| Course | Catalogue offering or course template | Straightforward |
| Session | Scheduled delivery instance | Straightforward |
| Sequence | Day-block within a session | Hard. Depends entirely on whether your target models multi-block sessions |
| Trainee or Employee | Learner record | Straightforward, watch for duplicates across entities |
| Instructor, Trainer and SME | Trainer record with skills and rates | Moderate. Skills and rate cards often need restructuring |
| Training Provider | External supplier | Moderate. Many systems have no equivalent object |
| Resource | Room, equipment or virtual room | Moderate. Booking history rarely transfers |
| Session cost lines and budget | Cost and margin tracking | Hard. Usually the least portable data in the system |
| Task | Workflow item on a session | Often abandoned |
| Catalogue entry | Published offering | Straightforward |
| Attendance and completion | Delivery record | Moderate. Depends on whether records live here or in your LMS |
The difficulty column is the useful one. It tells you where to spend your project time, and it tells you which conversations to have with your new vendor before you sign, not after. Our guide to training management software features is a reasonable checklist for that conversation.
What usually does not transfer
Every migration loses something. Naming it in advance turns a nasty surprise into a planned decision.
Cost and budget history. Training Orchestra’s budget tracking is one of its distinguishing features, and it is correspondingly hard to move. Cost structures, allocation rules and historic margin data rarely have a direct equivalent elsewhere. Most teams export it to a warehouse or a spreadsheet archive and start fresh in the new system. Plan for that rather than discovering it in week ten.
Task and workflow state. Open tasks attached to sessions are internal workflow, not business records. They almost never survive, and they almost never need to.
Configuration. Approval chains, notification rules, permissions and custom field logic have to be rebuilt in the new system. Nothing exports them. Budget real time for this, because for most teams it is a larger effort than the data move itself.
Attachments. Documents attached to sessions, trainers or trainees, such as signed attendance sheets, contracts and certificates, usually require a separate retrieval, and often a manual one.
Audit trail. Who changed what and when stays behind. If you are in a regulated industry, keep read-only access to the old system for as long as your retention obligations require, and confirm what that costs before you serve notice.
Resource booking history. Future bookings need to move. Past bookings almost never do, and rarely matter.
Suggested Reading: SimpliTrain vs Training Orchestra: TMS Comparison 2026
How to export data from Training Orchestra
Here the guide has to be honest about a limitation: Training Orchestra does not publish a public developer portal or open API reference. As of August 2026 we could not find one. Integration documentation from partner platforms confirms that API credentials are issued by Training Orchestra directly. Docebo’s own connector documentation instructs customers to contact Training Orchestra to obtain them.
That has a practical consequence. Your extraction options depend on a conversation with your account manager, and that conversation should happen early, ideally before you give notice.
What the public connector documentation reveals about the API
The clearest publicly available specification comes from third-party integration docs. Edusign’s connector documentation describes the shape as:
- OAuth-style authentication using a client ID and client secret, against a token URL and a versioned base URL
- Two distinct API surfaces: an OF interface (organisme de formation, meaning external and commercial training) and an RH interface (ressources humaines, meaning internal employee training). Which one your data sits behind depends on how your instance is configured, and some organisations use both
- Retrievable objects including students and employees, instructors, the Course to Session to Sequence structure, and enrolments
Two constraints in that documentation are worth flagging, with the caveat that they are described in the context of one specific connector and may not apply to a bulk extract. First, sessions are retrieved only when their status is Validated or In Qualification, so sessions in other states may not appear. Second, that connector retrieves only sessions falling in the next 15 calendar days.
If a similar window applies to your extract, a naive API pull will return a fortnight of scheduling and none of your history. Ask Training Orchestra directly whether a date-bounded historical extract is available, and get the answer in writing.
Your realistic extraction routes
- Request a full vendor-assisted extract. Ask for every object, in a documented format, with a data dictionary. Put the request in writing, with a date. This is the cleanest path and the one most likely to capture the objects the API does not expose.
- API extraction, once credentials are issued and you have established whether date and status filters constrain what you can pull.
- Report exports from the interface, as a fallback and as a cross-check. Slower and usually partial, but useful for reconciliation.
Whichever route you take, request the extract twice: once early, as a test file to build and validate your mapping against, and once at cutover as the live load. Building a mapping against a sample and then discovering the real export has different columns is a common and entirely avoidable delay. Our guide to exporting data from Saba walks through the same principle on a different platform.
Timing your exit: contract, notice and choosing the right month
Training Orchestra sells three packages, Essential, Professional and Enterprise, all quoted rather than list-priced. Contract length, notice periods and renewal terms are not published, so yours are whatever your agreement says. Read it before you plan anything else.
Three things to establish:
- Notice period and renewal date. Missing a notice window by a week can cost you a year.
- Post-termination data access. How long can you still log in and export after the contract ends? This is the clause that determines how much schedule pressure your project runs under.
- Whether extract assistance is chargeable. Some vendors treat migration support as a billable service. Better to know in the planning stage.
On when to cut over, pick your quietest delivery period, not your financial year end. Everyone’s instinct is to align a system change with the fiscal calendar. In a training business that is usually the worst possible choice, because it collides with budget close, renewal season and reporting deadlines. Look at your delivery calendar instead and find the four-week window with the fewest scheduled sessions.
How to cut over without disrupting live training
You cannot pause a training operation. People are booked onto courses next week, trainers have committed dates, and rooms are held. This is what makes a TMS migration harder than an LMS migration, and it is the part almost no migration guide covers. We looked at the same problem from a different angle in switching training management software without disruption.
The sequence that works:
- Set a booking freeze date. From this date, all new registrations go into the new system only. Existing bookings stay where they are for now. Communicate this internally with more warning than feels necessary, because sales and operations teams will otherwise keep booking into the old system out of habit.
- Load history first. Migrate completed sessions, historic learners and past attendance well ahead of go-live. This data is static, so it can be loaded, checked and corrected without time pressure.
- Load the forward schedule second. All sessions scheduled after your go-live date, with their registrations. This is the critical load and it needs the most validation.
- Run a delta load immediately before cutover. Between your first forward-schedule load and go-live, bookings will have changed: cancellations, transfers, new registrations. A final delta pulls those across. Do not skip it and do not assume nothing changed.
- Run in parallel for two to four weeks. Both systems live, with the old one read-only for new bookings. This is your insurance. Resist the pressure to shorten it.
- Decide what happens to sessions running across the cutover. A course that starts three days before go-live and finishes two days after needs an explicit owner and an explicit system. Make this call in advance for every affected session. There are usually fewer than you fear, but each one needs a decision.
Do not forget the operational plumbing
Three things that break quietly after a TMS migration, in roughly the order they cause damage.
Email deliverability. Your new system sends joining instructions, reminders, confirmations and certificates from your domain. If SPF and DKIM are not configured for the new sender before go-live, those emails land in spam, and nobody notices, because nobody complains about an email they never received. They just do not turn up to the course. Set this up two weeks early and send test messages to external addresses on the major providers. Platforms with built-in automated training notifications make this easier to verify before you switch.
Calendar invitations already issued. Invites sent from Training Orchestra are sitting in learners’ and trainers’ calendars. They will not update themselves. Decide whether to reissue from the new system, and if you do, warn people first, because a wave of duplicate invites for courses they have already accepted generates a lot of confused emails.
Integrations. Every connection to your HRIS, LMS, virtual classroom platform, CRM and finance system needs rebuilding and retesting. Inventory them at the start of the project. Teams routinely discover a forgotten nightly HRIS sync in week eleven. Check what your replacement supports through its integration options before you commit.
If you are a commercial provider with a public catalogue on your website, add a fourth: the URLs of your course pages and any embedded booking widget. Changing systems can change your URL structure, which can cost you organic traffic that took years to build. Map old URLs to new ones and put redirects in place on the day you switch, not the week after.
Validating the migration before you go live
Set numeric pass criteria before you start, then check them against the loaded data. Vague confidence is not a test.
- Record counts for each object, meaning learners, sessions, registrations and trainers, against the source extract, with any variance explained rather than tolerated
- Every future-dated session present, with correct dates, times, timezones and, critically, correct sequence structure for multi-block sessions
- Registration counts per session matching exactly, including waitlists and cancellations
- Trainer assignments on every forward session
- Certificate and qualification expiry dates intact. Check these individually if you operate in a regulated sector, because a shifted expiry date is a compliance problem, not a data problem
- Financial totals reconciled against your finance system for any period you migrated
- A full end-to-end test: create a booking, trigger the confirmation email, check it arrives, run the session, mark attendance, issue the certificate
Get an operations person who was not part of the project to run that last test. People who built the configuration are the worst testers of it. Our migration checklist guide covers the validation stage in more depth.
How long a Training Orchestra migration really takes
For a mid-sized training operation with a few thousand learner records and a busy forward schedule:
| Phase | Typical duration |
|---|---|
| Scoping, data audit and mapping decisions | 2 to 3 weeks |
| Extract request and delivery | 1 to 3 weeks, largely outside your control |
| Build, configure and transform | 3 to 4 weeks |
| Test load and validation | 2 weeks |
| Delta load, cutover and parallel run | 2 to 4 weeks |
That lands between eight and fourteen weeks. Two variables move it most: how quickly Training Orchestra turns around your extract request, and how much of your configuration, meaning approval chains, notification rules and cost structures, has to be rebuilt by hand.
Enterprise environments with multiple entities, several HRIS feeds or regulated record-keeping should plan for the upper end or beyond. What happens after go-live matters too, which we covered in implementation after migration.
Mistakes specific to Training Orchestra migrations
- Treating Sequences as an afterthought. Decide how multi-sequence sessions map before extraction, not during load. Retrofitting this decision means redoing the whole schedule load.
- Assuming one API covers everything. If your instance uses both the OF and RH interfaces, an extract from one gives you half your operation. Confirm which surfaces your data sits behind at the start.
- Requesting the extract too late. It is not self-serve, and it is not instant. Ask for it during evaluation, before you commit to a timeline you cannot control.
- Trying to migrate budget history. Usually not portable, usually not worth it. Archive it and move on.
- Underestimating configuration rebuild. The data moves faster than the rules around it. In most projects, rebuilding approvals, notifications and permissions takes longer than moving the records.
Frequently asked questions
Does Training Orchestra have an API?
Can I export my data from Training Orchestra myself?
Is Training Orchestra an LMS?
How long does it take to migrate off Training Orchestra?
Will I lose my training history?
What happens to courses already scheduled and sold?
When is the best time to migrate?
Do I need to keep access to Training Orchestra after migrating?
Where to start
Before anything else, settle the Sequence question. Take three of your most complex multi-block sessions, write down exactly how they would need to be represented in whichever platform you are evaluating, and get the vendor to confirm it in writing. That single decision shapes the extract, the mapping and the schedule load, and it is far cheaper to answer now than in week ten.
Book a demo to see how SimpliTrain handles multi-sequence sessions, instructor allocation and resource booking in one platform, and to work through the mapping table above against your own Training Orchestra configuration.
