What to Check Before You Migrate a Question Bank

Question banks lose three things in a migration: question types the new system cannot represent, the bank structure that organized them, and the metadata nobody thinks to check. Content usually survives. Classification usually does not. Plan two import passes, not one, and test with a real sample of your own items rather than the vendor's.

This guide assumes you have chosen a system. If you are still deciding, the buyer's guide to university exam software covers migration as a procurement question. What follows is the week between signing and importing.

What actually breaks in a question bank migration?

Losses come in three layers, and they are not equally visible.

Content is the item itself: the stem, the options, the key. This nearly always survives, because every system stores it and every importer reads it.

Structure is how the items were organized. Folders, sub-banks, ownership, access. This survives less often, and usually arrives through a separate route. A migration is also the one moment when rebuilding it is cheap, so it is worth deciding how the bank should be structured before you move anything.

Metadata is everything you attached to make the bank usable: tags, difficulty, authorship, review dates, and the performance history of each item. This is the layer that quietly disappears.

Most migration plans budget for the first layer. The third is the one that costs a year of work.

What should you get out of the old system first?

Before you look at any import template, take four things out of the system you are leaving.

An item inventory by question type. Count how many items you have of each type. This single number tells you how much of your bank is at risk, and you cannot get it after you leave.

The answer key as its own artifact. Export it separately, in a plain format you can read. Keys travel inside proprietary formats and are the first thing to break silently. A key that shifts by one column is worse than a key that fails to import, because nothing tells you.

A count of items carrying images, tables, or formulas. These are the slowest to repair and the easiest to overlook. You need the number to estimate the work.

The bank tree, on its own. Write down the hierarchy: names, nesting, who owned what. You will almost certainly rebuild it by hand or import it separately.

Do this while you still have a license. Access to an old system ends on a date, and that date always arrives sooner than the migration finishes.

Which question types actually survive?

Every importer supports a subset of the types its own system can store. The subset usually consists of the simple ones: single-answer multiple-choice, multiple-response, true/false, short answer, essay.

The casualties are the structured types. Matching, ordering, fill-in-the-blank, and anything needing a file upload rarely come through a generic importer. There is no agreed way to express them in a spreadsheet row. Clinical station formats almost always require their own importer and template.

So ask for the list of supported options in writing before you sign. Then compare it against the inventory you took. The difference is your rebuild backlog, and it is better to know its size in week one than in month four.

One more thing to ask: does the importer detect duplicates? Usually not. A bank merged from three departments will arrive with its duplicates intact.

Does the structure come across, or just the questions?

This is the check people skip, and it is the one that produces the ugliest surprise.

In most systems, the bank taxonomy is imported separately from the items themselves. You import the tree, then you import the questions into it. Run them in the wrong order, and every question lands in one undifferentiated pile.

Nesting depth is also usually capped. If your old bank ran eight levels deep and the new one allows five, you need a flattening plan before you import, not after.

Plan two passes. Structure first, items second, and a check between them.

What disappears quietly?

Four kinds of metadata rarely survive, and none of them announces its absence.

Tags and classification. The topic, competency, and outcome labels that enable blueprinting. Losing these does not break anything on import day. It breaks the first time someone tries to build a blueprinted paper.

Author-assigned difficulty. Often a per-item value someone spent real time setting. Bulk reassignment after the fact is rarely supported, so check whether the import template carries a difficulty column at all.

Version history and authorship. Who wrote the item, who revised it, and when. This matters at appeal, and it does not move with the item.

Item statistics. The accumulated performance data — difficulty, discrimination, distractor behavior — belongs to the administrations that produced it, not to the question text. Expect to start again. Item analysis rebuilds after a few sittings, but it does rebuild from zero.

Decide deliberately which of these you will re-enter by hand, and which you will let go. The worst outcome is discovering the choice was made for you.

How do you test an import before you trust it?

Never import an entire bank in a single action. A good importer makes this easy by separating parsing from committing.

StudyDrome Exam Manager splits it in two. The file is parsed first, and every row comes back validated with its own errors. Nothing is written until you pick a target bank and commit; the commit then re-runs the same checks on the server. The question importer reads Excel and Word and extracts embedded images — see importing questions from Word for what that does and does not include. It handles five question types. Bank structure and clinical stations each have their own templates and passes.

Whatever system you are moving to, run the same drill:

1. Take a real sample of your own items, including the awkward ones — long stems, images, tables, unusual types.
2. Import the sample into an empty bank.
3. Read every row error, not just the count.
4. Open ten imported items and compare them against the originals, option by option.
5. Build one short test from the sample and preview it as a candidate would.

Step four is the one people skip. Row errors catch what failed. Only reading the items catches what imported wrongly.

Find the limits before you plan the passes. Importers cap file size and rows per upload, and the caps differ by importer within the same system. Questions, students, groups, and access restrictions each have their own ceiling. A bank of 6,000 items and a roster of 4,000 students will not arrive in a single action, so work out the number of passes early and assign each one an owner and a checkpoint.

One last thing, and it is a staffing point rather than a technical one. Rebuilding unsupported items is content work, not IT work. It needs the people who wrote the questions, and they have teaching loads. Book that time in the same week you agree the contract, because it is the constraint that actually sets your go-live date.

The pre-flight checklist

Two habits make the difference. Do the inventory before you lose access to the old system. And treat the first exam built from the migrated bank as part of the migration, not as business as usual.

Frequently asked questions

What does not come across when you import a question bank?

Content usually arrives intact. Structured types often do not — matching, ordering and fill-in-the-blank. Nor does the bank hierarchy, which is normally a separate import. Tags, author-assigned difficulty, version history, authorship and accumulated item statistics all tend to be left behind. Ask for the list of supported question types in writing, then compare it against your own bank's inventory.

Can you import SCORM or QTI packages?

Usually not, whatever a feature list implies. Most exam systems import spreadsheets and word-processor documents against a fixed template. Interoperability packages are far rarer in practice than in marketing. If a round-trip matters, ask for a demonstration using one of your own packages rather than a sample, and confirm what comes through it.

Are there data import and export formats?

Ask this as two questions, because the answers differ. Import formats are usually a short, fixed list with a downloadable template for each format. Export is often narrower, and results export is not the same as item-bank export. The question that matters for your next migration is whether you can get your questions back out, not just your reports.

Can you import a batch of students at the same time?

Normally, yes, through a separate importer with its own template and row limits. Student, group, and access-restriction imports are usually distinct from question import, so plan them as separate tasks with separate owners. Check the per-file row cap early, because a large institution often needs several passes rather than one.

Do you still own the questions you upload?

Ownership belongs in the contract, not on a help page. Confirm two things before signing. First, that you keep ownership of the items you upload. Second, that you can export them in a usable format at any time, including on exit. The second matters more, because ownership without export is ownership you cannot act on.

How long should a question bank migration take?

Budget by rebuild volume, not by bank size. Items that import cleanly take hours, however many there are. Items that need rebuilding take minutes each, and structure and tagging usually take longer than the items do. A bank where 15% of items use unsupported types is a several-week project. The inventory tells you which case you are in.

Where to go next

For the question types a bank can hold once it has moved, see the eleven question types. For how importing works in practice, see Exam Manager.

For the file itself — block markers, the field grammar, and which image formats convert — see importing exam questions from Word.

For the statistics that rebuild after your first few sittings, see reading an item analysis report.

Migration is also a chance to leave items behind. Writing flaw-free MCQs covers what a question needs to earn its place in the new bank.