One of the main issues RTOs face when looking to adopt a new and hopefully, better student management system is the dreaded ‘data migration’ phase.
Let’s face it, if you’re an established RTO you probably have years’ of student records that you’re obliged to keep. Now you need to migrate them to a new student management system. Naturally you’ll have questions.
- How will the data be migrated?
- Do I have to migrate all the data or just active records?
- Do I need to clean up my data before migrating?
- Can I archive completed records?
- How will this work with my AVETMISS / HEPCAT reporting?
- How much does it cost to migrate data?
- What if my data isn’t suitable for migration?
- What about documents, certificates, templates, reports etc.?
- What format should I provide the data in?
- What if I add new records to my old system after my data’s been imported?
These are the really good questions that concern most of the RTOs I’ve come across. Why, you ask, do so many RTO’s quiver at the thought of data migration? After all we’re just moving AVETMISS data in the same format from one system to another. What’s the big deal?
You’re right! It shouldn’t be a big deal – but these questions are still common because so many RTOs have been burnt by enthusiastic, over-confident system vendors who haven’t taken the trouble to think through this critical steps of transitioning an existing RTO to the new system.
If you’re in the market for a new system and have these concerns (and you should!) then read on.
What do I know?
I’ve been providing training, learning and student management systems to RTOs in all categories for the past 12 years. Transitioning RTOs to new platforms has been of interest to me since 2006, when AVETMISS 6.0 and the AQTF 2007 guidelines were introduced, with different implementations in every state right up to present day when you’re about to embark on a new journey with AVETMISS 8. In this period, we’ve all seen some of the most dramatic changes to the VET landscape.
Including: AVETMISS versions, USI, Vet Student Loans, ESOS standards, AQTF SRTO – you name it! And also regulator changes, e.g. AQTF to ASQA and the various state level authorities. You rightly expect to come through these battles alive and still in relatively good health. On each occasion we as student management system vendors had to do three things really well:
1. Ensure your new software complies with the latest changes.
2. Ensure your existing data continues to be reportable
3. For those of you on the move, ensure that the data imported from your old student management system can continue to be reported in the new system.
You want and expect minimum downtime and normal business continuity.
I’ve managed to fill books of lessons-learned on this subject. Now I can share the most important lessons to help you transition to your new system with minimal scar tissue.
Lesson 1: If you only deliver nationally accredited training your transition to a new system should be painless.
I stress should because that really depends on your prospective new vendor. To put it simply, let’s say you’ve been consistently reporting compliant data, in accordance with a nationally accepted standard like AVETMISS, HEIMS or HEPCAT. Then we can reasonably assume your reported data is accurate and compliant.
Any vendor worth his salt should be able to effortlessly import compliant data into their hopefully, ‘compliant’ system – you would think! But if your prospective vendor hasn’t developed adequate import tools – then you’re no better off than say a non-registered training provider who made up their own in-house reporting standards.
The lesson here is – choose a vendor who’s taken the trouble to develop reliable import tools that minimise your data-migration costs.
But what if it’s been a while since you last reported? How can you be sure your most recent data is compliant?
In this case use the NCVER AVS tool to test the latest records you want imported. You can also run test submissions on just about any state or national RTO reporting system. But it’s in your interest to be as confident as you can be in the quality of your data.
Lesson 2: What if you have a mix of accredited and non-accredited training, or even no accredited training?
This is common with Enterprise RTOs, where the RTO side of the business is not always the number-one focus. If you deliver a mix of accredited and non-accredited staff training then you won’t benefit from any automated data-migration tools that your vendor may have created.
But here again, your prospective new vendor can still play an important role in minimising your data-migration costs.
A good vendor will have thought through the process and come up with a set of import Templates in Microsoft Excel for example. They will have developed tools to import data from those templates. In theory, all you should have to do is export data from your existing system and copy-paste or rename columns to be consistent with the vendor’s templates.
Again I emphasise the word should. There are other considerations, e.g. you might even use exactly the same column names as the vendor, but your data types or formats may be different. Also, the vendor may have “import validation rules” that result in your data being rejected, example: expected date format is: 23/05/2011 vs. your date format: 23rd MAY 2011.
There are systems available that enable you to map your column headers to the vendors and that cater for a wide variety of import data types and formats.
Lesson 3: How do you deal with data columns that you can’t match?
Again this is a common requirements, particularly if you’re an Enterprise training provider, registered or not. Often you need to collect data that is specific to your industry or your organisation that you won’t find readily in a commercial-off-the-shelf (COTS) system.
And once again, vendors who’ve thought about these problems can still offer solutions that minimise your data-migration costs. I handled this scenario by building a bank of spare fields with different data types: free text, true/false, date-time, number, etc… These fields can be assigned and relabelled by my client. For example, a common requirement for public safety officers is ‘currency in and accredited role or capability’.
This requires ongoing professional development and assessment, say annually. The feature requires a ‘currency expiry date’ field. The client was able to utilise one of the spare date fields which was relabelled to “Currency Expires”. These fields can be (optionally) included in reports and searches. This type of preparation provides a zero-cost implementation in what would otherwise have been an expensive customisation project.
Mismatches can go both ways of course. What if the vendor requires a data item that your existing system doesn’t provide?
A good vendor will enable any mandatory data to be defaulted. So if your current system doesn’t provide a necessary piece of data then you can set an appropriate default value to satisfy your new system. Obviously since you’ve never captured this data in the past it’s not important to you, so a default value that satisfies the new system is generally a good option.
Lesson 4: Do I have to migrate all the data or just the records that are currently active?
You’d probably prefer to have all of your data in one system, rather than having to work with a separate archive system that holds all your completed activity and transfer only active records to your new system.
But I’ve had requests from RTOs who want to ‘park’ the old stuff and keep their new system light and clean.
In a perfect world both should be possible. But if you decide to archive your old data keep these two points in mind.
1. If you collect state funding and need to report monthly, e.g. to DET Queensland, Skills Vic or RAPT in WA your state training authority will be looking for consistency across the current reporting year. Students who were reported as completed last month are generally expected to again be reported as completed in the current month.
If this is your situation then you should consider any training activity in the current year as active and reportable.
2. In my experience the most common call on archived data is for lost or expiring certificates. If your old system regenerates certificates from original data then you should create re-printable backups, e.g. PDF copies of all certificates before archiving the old system.
If you choose to migrate all the data the new system should handle completed vs. current training activity differently. For example, you probably don’t want your daily admin activities bogged down with large volumes of completed records that you’ll rarely need to access.
A good system separates the data so that you can focus on current and future activity, safe in the knowledge that you can easily access completed activity if and when you need to.
This rule may not apply in Enterprise and Public Safety scenarios where it may be common to access a person’s profile and training history for HR and incident-deployment considerations.
Lesson 5: What about documents, certificates and templates?
Your current system may store these as either data or as documents on a file server. Either way there should be a facility to export them as documents. Of these, the most important are your issued certificates. As an RTO you’re obliged to keep copies of these.
As a general rule templates are neither as numerous or as critical as issued certificates and if you had to recreate these from scratch I a new system that would not constitute a major melt-down. But where possible transfer them to the new system and get pdf copies of your templates so that they can be recreated in the new system if necessary.
Course documentation, online learning packages (SCORM / xApi), Assessment Tools should all be transferrable to your new system, if supported! By now you will probably have established that if your business needs these documents and your prospective new system doesn’t support them then you have a needs-gap that should be addressed.
In summary
Data Migration is not something you should be scared of. In fact, it’s a decision you’ll have to make sooner or later when migrating to a new system.
An important step in your preparation is selecting a vendor who has done the necessary preparation and developed the right set of migration tools, automated procedures and documentation to make this critical phase as painless and inexpensive as possible.