How to Migrate From Administrate: 2026 Guide

Administrate is one of the more technically open training management systems to leave, and one of the more conceptually confusing. The export side is genuinely good: two documented GraphQL APIs cover most of what you need, and you can pull your own data without waiting on anyone. The difficulty is in the model. Administrate draws a distinction between a Contact and a Learner that most other systems do not make, invoices at Event level rather than Session level, and carries objects like Training Tokens and Unnamed Delegates that have no obvious equivalent anywhere else.

Get the mapping right and this is a straightforward migration. Get it wrong and you will discover in testing that you have imported participation records instead of people, and that several customers have prepaid course credits nobody accounted for.

Budget eight to twelve weeks for a mid-sized training provider, including two to three weeks of parallel running. This guide covers the export routes, the mapping traps, what does not come across, and how to time the switch. It is written to be useful regardless of which platform you move to.

Why training providers leave Administrate

Administrate has been repositioning upmarket for several years, and most of the churn traces back to that.

Renewal pricing is the loudest complaint. Public reviews on Capterra describe a price increase of 150 percent at renewal, and another customer reports a subscription that tripled while the accounting module was removed from their plan. Phone support has also been withdrawn for some tiers. Whatever the commercial reasoning, the effect is that customers who bought Administrate as a mid-market product have found themselves renewing into enterprise pricing.

The interface shows its age. Reviewers describe it as clunky, slow and dated, with users being logged out on refresh. Ratings reflect it: around 3.6 out of 5 on G2 across a small review base, against 4.5 or higher for several competitors.

Invoicing works at Event level, not Session level. For providers who sell individual sessions within a longer programme, this creates persistent workarounds. Reviewers also report double-charging when a delegate changes course.

Implementation is heavy. Administrate markets onboarding in as little as 12 weeks, and reviewers describe standing it up as taking months. For a small or mid-sized training company, the administrative model is a lot of machinery.

The LMS side lags. Administrate’s strength is training operations. Its learning platform is consistently described as behind newer products, which pushes some customers into running a second system rather than a unified learning platform.

Set against that, the API is well documented, the CRM and operations functionality is deep, and the reporting engine is powerful if frustrating. If your problem is price rather than capability, negotiate before you migrate. Migration is a large project to undertake for a commercial dispute you might win at the table.

The mapping trap: Contacts are not Learners

This is the most important thing in this guide, so it goes first.

In Administrate, a Contact is a durable record of a person. It persists over time, holds their identity, and belongs to an Account, which is the organisation they work for. A Learner is something different: it is a record of participation, scoped to an event. Administrate’s own course management documentation puts it plainly, that Contacts represent people over time while Learners represent participation rather than identity.

Most systems do not split those. They have one person record, with enrolments attached.

The practical consequence is that if you export Learners and treat that file as your people list, you will create a duplicate person for every course they have ever attended. A customer who has been on six of your courses becomes six learner records. Deduplicating after the fact is painful, because by then registrations, certificates and email history are attached to the wrong records.

So the rule is: Contacts and Accounts are your identity layer, and Learners are enrolment data. Export both, map Contacts to person records and Learners to registrations, and use Administrate’s external ID fields to hold the join key.

Administrate’s data model, mapped

The training hierarchy runs Course Template, then Event, then Session. A Course Template defines how training should be delivered, including defaults and rules. An Event is the actual instance, covering when, where and how. A Session is a scheduled block inside an Event, which is how a three-day course is represented as three dated blocks.

Alongside that sits a genuine CRM layer, which is unusual for a TMS and matters when you plan the move.

Training Passes and Tokens deserve their own paragraph

If you sell prepaid training credits, bundles or seat blocks, those live in Administrate as Training Passes and Training Tokens. They represent money customers have already paid for training they have not yet taken.

That is a financial liability sitting in a system you are about to switch off.

Every unredeemed token has to arrive intact in the new platform, with the correct remaining balance, the correct expiry, and attached to the correct account. If your new system has no equivalent object, you need a plan before you sign, whether that means a manual credit balance, an agreed reconciliation with each affected customer, or a decision to honour them outside the system. This is the single most likely thing to cause a customer-facing problem after go-live, and it is almost never in a migration checklist. If prepaid bundles are core to how you sell, check how your replacement handles training monetization and e-commerce before you commit.

Unnamed Delegates

Administrate lets you reserve places on an event without naming the person yet, which is how corporate bookings often work in practice. Most systems handle this differently or not at all. Decide early whether these become named placeholder records, a held capacity count, or something you resolve with customers before cutover.

How to export your data from Administrate

Unlike some competitors, Administrate publishes real developer documentation, and you can extract most things yourself. Two things to understand before you start.

There are two separate GraphQL APIs, and you need both.

The Core API covers the CRM and operations side: Accounts, Contacts, Individual Accounts, Sales Opportunities, Course Templates, Events, Locations, Registrations, Learning Paths, Training Passes and Training Tokens. It also exposes custom fields, documents, external IDs and webhooks, and includes an interactive editor for testing queries before you run them at volume.

The LMS API is separate and covers Learners, Courses, Learning Paths, Achievements, Certifications and Outcomes. Its visibility is scoped to what the viewing contact is permitted to see on an LMS portal, which is a meaningful constraint on bulk extraction and worth testing early.

If you only pull from the Core API, you will be missing your learning records. If you only pull from the LMS API, you will be missing your entire commercial layer.

The legacy REST API still exists. Older documentation covering v2 behaviour, orders, unnamed delegates, events and document templates remains published. If your existing integrations run on it, inventory them now, because whatever you build next will not use it. We could not find a published sunset date, so ask your account manager directly rather than assuming.

A practical extraction sequence

• Get API credentials and test with small queries first. Use the interactive editor to confirm the shape of what comes back before you write anything.
• Pull reference data first: Accounts, Contacts, Locations, Instructors and Course Templates. This is your foundation and it changes slowly.
• Pull operational data: Events, Sessions, Registrations, Learners, Training Passes and Tokens.
• Pull learning records from the LMS API: Achievements, Certifications and Outcomes.
• Cross-check with report exports from the interface. Administrate’s reporting engine is capable, and running the same counts through reports gives you an independent check on your API extract. Discrepancies here are worth chasing before you go further.
• Capture your custom fields explicitly. They are exposed through the API but they are yours, which means nobody else’s mapping template covers them.

Two operational notes. The API enforces rate limits, so a large extract needs pagination and patience rather than brute force. And Administrate documents CSV import thoroughly while a comparable bulk export article is not publicly available, so plan on the API plus reports as your route out rather than a single download button.

One more thing to check: a recurring complaint from customers migrating into Administrate is that private events cannot be imported. If you have ever hit that limitation from the other direction, be aware that private and closed corporate events may behave differently in your extract, and test them specifically.

What usually does not transfer

Document templates. Certificate layouts, joining instructions and invoice templates have to be rebuilt. Screenshot every one before you lose access, because reconstructing a certificate from memory is miserable.

Reporting and dashboards. Every saved report and dashboard is configuration. None of it exports. List the reports your business actually runs on before you leave, and rebuild only those. Most organisations find the list is far shorter than the number of reports that exist. Our piece on training reporting KPIs that matter is a useful filter for that exercise.

Workflow and automation rules. Notification triggers, approval chains and permission structures are rebuilt from scratch.

Sales Opportunities. Technically extractable, but they usually belong in your CRM rather than your new TMS. Decide where pipeline data lives before you move it somewhere it will rot.

Email history and system-generated communications. Records of what was sent to whom generally stay behind. If you have a compliance reason to retain them, extract to an archive.

Audit trail. As with any platform, change history does not travel.

Timing your exit

Administrate prices on annual learner volume and the size of your admin team rather than the number of instructors, and contracts are negotiated individually. Two dates matter more than anything else in the project plan.

Your renewal date. Given the pattern of steep renewal increases in public reviews, this is your point of maximum leverage and also your natural deadline. Start the evaluation at least six months out. If you intend to negotiate rather than leave, having a real migration plan in hand changes that conversation considerably. Our training management software buyer’s guide covers what to compare.

Your notice period. Read the clause. Then read the clause about how long you retain access to your data after termination, because that determines whether your migration runs comfortably or under pressure.

For the cutover itself, pick your quietest delivery window rather than your financial year end. Training businesses have their own seasonality and it rarely aligns with the accounting calendar.

Cutting over without disrupting live training

Bookings do not pause for a system change. The sequence that works, covered more generally in our guide to switching training management software without disruption:

• Set a booking freeze date. After this date, new registrations go into the new system only. Tell the sales and operations teams repeatedly, because habit is stronger than an email.
• Load history first. Completed events, past registrations, historic contacts and achievements. This data is static, so load it early and fix it without deadline pressure.
• Load the forward schedule second, with registrations, instructor assignments and room bookings. This is the load that has to be perfect.
• Reconcile Training Tokens and prepaid balances separately. Do this as its own workstream with someone from finance involved. Do not fold it into the general data load.
• Run a delta load immediately before cutover. Between your forward-schedule load and go-live, bookings will change: cancellations, transfers, new registrations, delegate name changes. Pull those across at the last possible moment.
• Run both systems in parallel for two to three weeks, with Administrate read-only for new bookings.
• Decide, in advance, which system owns each event that spans the cutover date. There are usually only a handful. Each needs a named owner.

The operational plumbing people forget

Email deliverability. Your new platform will send joining instructions, reminders and certificates from your domain. Configure SPF and DKIM at least two weeks before go-live and test against real external mailboxes. Emails that silently land in spam produce empty classrooms, and nobody reports an email they never got.

Your public catalogue and booking pages. If your course pages are indexed and your booking flow is embedded in your website, changing platform can change your URLs. Map old to new, put redirects live on cutover day, and check your conversion tracking still fires afterwards.

Integrations. Inventory everything connected to Administrate: accounting, CRM, virtual classroom, SSO, marketing automation, and anything built on the legacy REST API. Each one needs rebuilding and testing against your new platform’s integration capability. This list is always longer than anyone expects.

Calendar invitations. Invites already issued from Administrate will not update. Decide whether to reissue, and warn people first if you do.

Validating before go-live

Set numeric pass criteria up front and test against them.

• Contact count reconciled, with duplicates identified and merged deliberately rather than accidentally
• Registration counts per event matching exactly, including waitlists, cancellations and unnamed delegates
• Every future event present with correct dates, times, timezones, session structure, instructor and location
• Training Token balances reconciled to the last unit, signed off by finance
• Certification expiry dates intact, checked individually if you operate under regulatory requirements
• Revenue totals for any migrated financial period reconciled against your accounting system
• A full end-to-end test: book a place, receive the confirmation, run the session, mark attendance, issue the certificate, raise the invoice

Have someone from operations who was not involved in the build run that final test. People who configured the system are the worst people to test it. Our migration checklist goes further on validation.

How long it takes

Eight to twelve weeks in total for a mid-sized provider. Administrate’s documented API makes the extraction phase faster than average. What slows projects down is the Contact and Learner deduplication, the prepaid token reconciliation, and rebuilding document templates and reports.

Mistakes specific to Administrate migrations

• Exporting Learners as your people list. Covered above, and worth repeating, because it is the mistake that costs whole weeks.
• Pulling from only one API. Core gives you the business. LMS gives you the learning records. You need both.
• Forgetting prepaid tokens. Money customers have already paid. Reconcile it as its own workstream.
• Assuming Event-level invoicing maps cleanly. If your new system invoices per session, your historical financial data will not aggregate the same way. Decide how you are handling that before you migrate any finance data.
• Leaving custom fields to the end. They are unique to you, so no template covers them, and they usually carry information your operations team depends on daily.

Frequently asked questions

Where to start

Run one query against each API before you do anything else. Pull a hundred Contacts from the Core API and a hundred Learners from the LMS API, put them side by side, and count how many distinct people are actually represented. That five-minute exercise tells you the true size of your deduplication problem and settles the biggest mapping question in the project.

Book a demo to see how SimpliTrain handles person records, prepaid credits and session-level invoicing, and to work through the mapping table above against your own Administrate configuration.