Migrating from Box

This article serves as a comprehensive reference guide for migrating data from Box to Google Workspace or Microsoft 365 using CloudM Migrate. It details the expected behaviors, connection requirements, and mapping logic necessary for a successful transition.

Planning & Strategy

Successful Box migrations require a clear understanding of the mapping between Box’s unique folder-centric model and the destination's architecture.

Feature Compatibility

The following table outlines the data types and features supported during the transition, alongside those proprietary to Box or unsupported by the migration engine.

Data Discovery

Before initiating a migration, perform a discovery scan. This identifies total item count, folder depth, and ownership structures to help prevent API throttling or path-length issues.

• For detailed instructions, see: Box Data Discovery.

Configuration

Follow the Migration Guide as the primary workflow. Use the following links for Box-specific details required for Source configuration.

Source Connection & Authentication

The connection to Box requires a Custom App to be configured within the Box Developer Console to provide necessary API access.

• Box - Source Connection Setup: General requirements and authentication workflow.
  • Box JWT Authentication Setup: Step-by-step guide for creating and authorizing the JWT Custom App.
• Box Source Settings: Detailed explanation of source-specific configuration options.

Shared Folder Migration Logic

While standard user migrations allow for a "multiple source users to single destination user" approach (configured via Configuration Advanced System Allow multiple sources), migrating "Shared folders" from Box to Google Shared Drives or Microsoft SharePoint follows a different logic and requires multiple batch configurations.

• Ownership & Identification: In CloudM Migrate, you must specify the owner (Export Name) for the migration. The specific shared folder must be identified in the Items to migrate Documents Path field using its unique ID.
• Performance & Multi-threading: Large shared folders can result in lengthy migration times if processed on a single worker thread. To utilize multi-threading effectively, it is recommended to break large folders into smaller sub-sets (by sub-folders).
• Destination Strategy: Migrate these sub-sets to different destination containers (e.g., separate Shared Drives or separate SharePoint sites) rather than folders within the same container. This prevents single-threaded bottlenecks and optimizes throughput.

Permission Mapping & Address Replacement

To ensure file and folder access is maintained, CloudM Migrate maps Box roles to the nearest destination equivalent.

• Permission Mapping: For a breakdown of how Box roles translate to Google and Microsoft roles, see: Box Permission Mapping.
• Address Replacements: If users are changing email domains, configure address mapping to ensure permissions are applied to correct destination identities. See: Domain and Email Address Mapping Guide.

Microsoft 365 Destinations

If your destination is OneDrive or SharePoint, the following automated adjustments may occur:

• Character Truncation: File or folder names exceeding destination path limits will be truncated.
• Illegal Character Renaming: Characters unsupported by Microsoft (e.g., " * : < > ? / \ |) will be renamed or replaced.
• Size Limits: Box supports larger individual file sizes than some Microsoft 365 tiers; CloudM Migrate will return a warning for such files.

Destination Configuration Guides

Once the source is configured, refer to these guides for destination-specific setup:

• From Box to Google Workspace
• From Box to Microsoft 365