Updated September 2026. This post first appeared in November 2024 as "Seven Tips to Optimize Archiving Performance with Teamstudio Export." We've revised it for Export 5.1, the move to 64-bit Notes clients, and the way most customers now use Export: as the engine of a migration off Notes/Domino rather than a way to park old databases.
Migrating a large Notes/Domino estate is a big job, and the export step is often where the calendar gets eaten. A single application with a few hundred thousand documents, rich text, attachments, and a design that grew for twenty years can take days to process if the setup is wrong, and hours if it's right. Multiply that across a few hundred applications and the difference is measured in weeks.
Teamstudio Export turns Notes applications into HTML, PDF, XML archives, SharePoint Lists, CSV, and (coming in Export 5.2) JSON. Whatever format you're heading for, the same handful of decisions determine how fast the job runs. Here are the seven that matter most, in roughly the order you'll meet them.
1. Only migrate what's actually used
The fastest export is the one you never run. Most Domino estates we see carry a long tail of applications nobody has opened in years, and every one of them you leave out of the plan is hours you don't have to spend exporting, checking, and storing it.
Before you size the project, find out what's really in use. Teamstudio Usage watches your servers and reports which databases are active and which user IDs are still doing anything, so you can make the keep/export/drop decision with data instead of guesswork, and shrink the list before Export runs a single job.
For everything that does make the list, decide up front whether it needs a full HTML or PDF archive, a structured data export to SharePoint, CSV, or JSON, or both. A data-only export is much lighter than a full archive, and many applications only need one or the other.
2. Set up a dedicated export workstation, close to the server
Export runs on a Windows workstation with a Notes client, and it talks to the Domino server constantly while it works. Put that workstation on the same network as the server. If you can't do it physically, a virtual machine in the server's network is the next best thing.
Two things to avoid: running Export across a VPN, which adds latency to every one of the millions of round trips a large export makes, and running it on someone's day-to-day laptop, where a reboot, a sleep timer, or a full disk can interrupt a multi-day job. A dedicated machine that does nothing else is cheap insurance.
3. Take the network out of the equation
Even on a good LAN, the network is usually the slowest part of an export. Two habits help.
First, ping the target server from the export workstation before you start. If latency is high, fix that before anything else; no other setting will make up for it.
Second, for large or complex applications, make a local replica or copy on the export workstation and run Export against that. Export then reads from local disk instead of pulling every document over the wire. This is the single biggest speed-up available for big databases, and it also means a network blip mid-job can't corrupt the run.
Processing time depends on more than document count. Design complexity, embedded views, large attachments, and doclinks that point into other databases all add work. If you want cross-database doclinks to resolve in the finished output, read our posts on doclink integrity and external doclinks before you start, because the order you export databases in matters.
4. Use the queue, and save your configurations
Export can process up to three archive operations at once. Anything beyond that goes into a queue and starts automatically as a slot frees up, so you can load up a whole batch of applications at the end of the day and come back to finished output in the morning. If one database hits an error, the queue moves on to the next rather than stopping the whole run.
If you have more applications than one machine can get through in your window, add a second export workstation (this requires an additional license) and split the list between them.
Export 5.1 added Save and Load buttons to the Export Data dialog. A complete data selection (the formula, view, or search that picks documents, plus the fields you chose and the order you put them in) can be saved and reloaded later. That matters for migrations because you rarely export a database once. You'll run a test export, review it, adjust, and run it again, and then possibly run it a final time on cutover day. Saving the configuration means the third run is identical to the second, and nobody has to rebuild the field list from memory.
5. Write to local disk, and keep security software out of the way
Set the archive, HTML, and PDF output folders to a local drive on the export workstation, not a network share or a cloud-synced folder. Writing thousands of small files over the network is slow, and sync clients like OneDrive or Dropbox will fight Export for every file. Export locally, then move the finished output to its long-term home in one copy operation.
If the workstation is a cloud VM, storage performance is a setting you choose, not a given. On AWS EC2, for example, IOPS, volume type, and burst credits all affect throughput, and a general-purpose volume that has run out of burst credits can slow an export to a crawl halfway through. Size the disk for the job.
Real-time antivirus scanning is the other common culprit. Every file Export writes gets scanned as it lands, which can double the time a large HTML export takes. Exclude Export's working and output directories from real-time scanning for the duration of the project, or coordinate with your security team on an equivalent exception.
6. Trim the design before you export
Export processes every view in a database, and old production applications tend to have a lot of them. We've seen applications with thirty-plus views where three were in daily use, and one archived application that shipped with 267.
If the output is going to be a read-only reference, whether HTML, PDF, or a data export, ask which views anyone will actually navigate in the archive. Make a copy of the database, remove the views that aren't needed, and export the copy. The original stays untouched, and the export runs in a fraction of the time. Export 5.1 can also archive hidden views if you need them, so the choice is yours; just make it deliberately rather than exporting all 267 by default.
7. Run Fixup, Compact, and Updall first
Old applications often carry minor corruption and stale view indexes that never bothered anyone in daily use but will surface as errors or slow spots during an export. Running Fixup, Compact, and Updall on the server copy before you export (or on your local replica, once you've made it) clears most of this up in advance.
It's a few minutes of server time per database, and it turns "the export failed at 3 a.m. on document 412,000" into a job that runs clean the first time.
Bonus: keep your Notes client and Export current
Notes 14 is 64-bit only, and older versions of Export, like older versions of any Notes add-in, won't run on a 64-bit client. If you're upgrading clients as part of the migration, upgrade Export at the same time. Export 5.1 also bundles its own .NET 10 runtime, so there's nothing else to install and no dependency on whatever .NET Framework happens to be on the machine.
On the export workstation itself, use the newest Notes client you have available, even if your servers are still on Domino 9 or 10. The client is where Export does its reading, and newer clients include fixes for rich text, attachments, and OLE objects that older ones don't. Export 5.1 added handling for corrupted Base64 attachments, Visio OLE objects, and @While formulas, and each release picks up more of these edge cases. Upgrades are free with an active license subscription.
Putting it together
The pattern behind all seven tips is the same: get the reading side (network, replica, client) and the writing side (local disk, no scanning) out of Export's way, cut the work down to what actually needs doing, and let the queue run unattended. Do that and the export step stops being the long pole in your migration plan.
If you're planning a migration and want a second opinion on your setup, get in touch. We've seen most of the ways this can go slowly, and we're happy to help you avoid them.