We completed this process on our production database last weekend. Hyland can give you a ball-park estimate for the downtime, but I HIGHLY recommend you get an EXACT copy of your database server (RAM, processors, database version) and copy your production database over to it so that Hyland can run a test on that and give you a very realistic time estimate. The time will depend on three main things:
- Processing power of your server.
- RAM allocated to your server.
- Number of records / size of the database.
Plan on needing roughly double your current size to manage the conversion. Hyland's scripts will get a record count of each table, then for each table, copy it (converting the INT to BIGINT), rebuild the indexes, verify row counts, drop the old table, rename the new table.
You will need a full backup before Hyland starts, and you need to stop all import processes and prevent all users from logging in. (OnBase System lockout works great for that, as long as you make sure services don't automatically start up.) Hyland can do their work in one fell swoop (one single downtime) or over the course of multiple downtimes. (They will have a list of tables from the test, and an estimate of how long each table takes, so they know how much they can get done in a couple hours, or how long you need to be down for some of the larger tables.)
Estimates will vary based on the items listed above, but here are some rough numbers to give you an idea:
- Health Care system running for just over ten years;
- Roughly 3TB of data in the database;
- Full backup takes just under two hours;
- Largest table took about 5 hours to copy and rebuild indexes;
- Estimated time for Hyland to run scripts was 20.5 hours;
- We planned for a 24 hour downtime and operational owners agreed to a single long instance;
- We had some issues, so we were down around 27 hours;
Plan on a LOT of communication with end users, so they know the full extent of what the downtime means. (No access to documents, no imports, no extracts, etc.)
