Migrate from File Cabinet

Bulk-migrate existing documents from the NetSuite File Cabinet into File Storage's cloud storage, with a configurable retention window before the File Cabinet copies are removed.

When to use this

Most accounts run this once shortly after installing File Storage, to move existing attachments off the File Cabinet and onto the cloud. After the initial migration, new files go straight to File Storage and the File Cabinet stays empty for those record types.

It's also useful when bringing additional subsidiaries online — the migration can be scoped per subsidiary using the enable flags on the Storage configuration record.

Prerequisites

  • File Storage installed; the records you want to migrate already have File Storage enabled (see Enable on a record type)
  • Administrator or FC Storage Admin role
  • A maintenance window if you're migrating a large volume of files — migration runs as a Map/Reduce job and can take an hour or more for large datasets

Walkthrough

Author input needed

A detailed Scribe walkthrough for the migration utility is being recorded. Until it lands, the high-level steps below describe what the migration does. Track the Scribe in the register (FS-HT-02).

The migration pipeline works in three stages:

  1. Scoping. The Storage configuration record carries a per-subsidiary enable flag for migration. Tick the flag for each subsidiary you want to migrate. Migration only acts on record types that already have File Storage enabled, so confirm that list first.
  2. Discovery. A scheduled Map/Reduce job walks every File Cabinet file attached to the in-scope record types and creates a migration source record for each one. The header migration run record gives a running total of files discovered and migrated.
  3. Transfer. Each source file is uploaded to S3 via the Portal API and a matching File Storage Files record is created on the original NetSuite record. The migration tracking record is marked migrated. File Cabinet copies are retained for the configured window (default: a buffer before deletion) so you can verify the migration completed cleanly.

After the configured retention window expires, a separate scheduled job removes the File Cabinet copies. Until then, the original File Cabinet file is still in place — making rollback easy if something looks wrong.

What success looks like

  • Open a previously File-Cabinet-attached record. Its files now appear in the File Storage Documents section, with the same names and content as before.
  • The migration run record shows file counts matching the totals you expected, with no failed rows.
  • Within the retention window you can still see the original File Cabinet copies; after the window passes they're gone and the records show Document Deleted as ticked on the File Storage Files record.

Gotchas

  • Migration only runs against File-Storage-enabled record types. If a record type isn't enabled in File Storage, its File Cabinet files are skipped. Enable the record types first, then run migration.
  • Per-subsidiary scoping. In OneWorld accounts, migration runs subsidiary by subsidiary. If a subsidiary's flag isn't ticked, its files aren't migrated.
  • Don't delete the File Cabinet copies manually during the retention window. The pipeline relies on the originals being in place to retry failed rows. Let the scheduled deletion job clean up at the end of the window.
  • Migration is one-way. Once a file is moved into File Storage, there is no built-in "demote back to File Cabinet" tool. If you change your mind on a record type, disable the File Storage widget there but the existing migrated files stay on S3.
Last Updated: