Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Scoping a Perceptive Content Document Export

This guide covers how to scope a Perceptive Content document export during the sales process. It lays out the questions to ask the client, so the effort gets sized correctly before we commit to an estimate. Use it when a client is migrating off Perceptive, archiving content, or needs documents and metadata handed off to another system.

 Questions to Ask the Client 

  1. What version of Perceptive Content are you on? Why it matters: iScript methods and behavior differ between versions, and older versions may need script rework or have limits on what we can pull. Also tells us if they're out of support.
  2. Are you licensed for iScript? Why it matters: Every export requires it, no exceptions. The export runs as an iScript, so without the license there's no project until they buy one. Confirm this before anything else gets scoped.
  3. Do you need annotations carried over (stamps, redactions, sticky notes, highlights)? Why it matters: Annotations live in Perceptive as a separate layer, not in the file. A native export drops them. Keeping them means rendering each document, which is slower and adds licensing requirements.
  4. If you need annotations, are you licensed for Output Agent? Why it matters: Output Agent is what burns annotations into the exported image. If they don't own it, that's either a license purchase on their end or annotations are off the table. Better to find out now than mid-project.
  5. What format do you want the documents exported in: a standard format like PDF or TIFF, or native? If native, what format are most of the documents in today? Why it matters: Native is the simplest and fastest, we just copy pages out of the OSM. Converting to PDF or TIFF adds processing time and can require Output Agent. A mix of native formats (TIFF, PDF, JPG, DOC) also affects whether the destination system can take them as is.
  6. Do you want a full export, or only documents within a certain date range? Why it matters: Tells us how many documents to expect, which drives run time and the estimate. 
  7.  Roughly how many documents are in scope? Why it matters: Good to know up front so we can scope the effort properly. The client can get this with a count against the IN_DOC table, and RPI can provide the queries if they need help. If the export is limited to a date range, the count should be filtered to that same range so the number reflects what we're actually exporting.
  8. Where will the exported files land: local disk or a network share? How much free space is available there? Why it matters: Network shares are slower and bring service account permission issues. Exports can come out larger than the OSM if we're converting formats, and running out of disk mid-export is a common failure.
  9. What is the final destination for the documents (new ECM, ERP, cloud storage, cold archive)? Does that system have an import format we need to match? Why it matters: The destination dictates the output. If the target system has a bulk loader with a required index file layout, we build to that spec. A cold archive nobody will load anywhere is a much simpler job.
  10. Do you want RPI to hand over the script for you to run, or manage the entire export?Why it matters: Biggest swing in hours. Script-only is build, test, document, hand off. Managed means we own monitoring, reruns, error handling, and validation for the full run, which can stretch over weeks on large volumes.
  11. Should multi-page documents come out as one file or a file per page?
    Why it matters: Perceptive stores each page as its own object. One file per page is the native behavior. Merging into a single multi-page PDF or TIFF is a conversion step with the same time and licensing impact as question 4.
  12. Will Perceptive stay live during the export? If so, do you need a delta run at cutover to catch new and changed documents? Why it matters: If users keep working while we export, the first pass is stale by the time it finishes. A delta means tracking what was already exported and detecting changes, which is extra build and a second managed run.
  13. What metadata needs to come with each document? Why it matters: Files without index data are close to useless in the new system. Index keys are easy. Custom properties take more work, and the output layout has to match whatever is consuming it.
  14. What access can you give us: VPN, server login, database access, a test environment to run against first? Why it matters: Access delays are the most common reason these projects start late. No test environment means we're testing in production, which changes how carefully we have to run and how long it takes.
  15. Is there a deadline driving this, like a license expiration or a go-live on the new system? Why it matters: A hard date combined with high volume may force parallel runs or a reduced scope. If their Perceptive license is expiring, there's no room for a rerun.

 

Important Notes

eForm data cannot be exported. If a client asks about eForms, set that expectation early. It is not something we can include in scope.

Exports are safe to run in Production. The script does not move or remove anything from Perceptive. It only writes out copies of the documents, so the originals stay in place and untouched. A test environment is nice to have but is not required.