How We Run Migrations at ClonePartner

Migrating data can be complex, but at ClonePartner, we have a streamlined process that ensures every detail is handled with precision. Here’s an overview of how we manage migrations effectively to meet diverse customer needs.

Step 1: Determine the Scope of the Migration

Every migration starts with understanding the scope. Here are some scenarios we often encounter:

• Time Period: Migrating data created during specific time frames, such as migrating tickets created in the last two years.
• Business Unit: Migrating records based on department or business unit.
• Compliance Requirements: Migrating data that meets compliance or data residency requirements.
• Customer Segment: Migrating data related to a specific project or customer segment, depending on business needs.
• Platform End-of-Life (EOL): Migrating content from retiring platforms to active ones before access is revoked.

Other Use Cases We’ve Seen at ClonePartner:

• Syncing only data from the past two years to minimize migration volume and go-live faster.
• Performing a partial migration initially, with a complete migration scheduled later to ensure smooth transitions.
• Migrating data over a weekend and running a delta migration afterward to cover new records generated during the migration period.
• Migrating only records associated with a particular office location to adhere to regional regulations or focus on localized data.

Custom Fields, Tags, and Users:

• Syncing Only Specific Custom Fields: For example, only syncing opportunities marked as “High Priority” in a CRM or tickets with custom fields that carry specific product names in a helpdesk.
• Syncing Data Based on Tags: Syncing tickets tagged with “VIP Customer” or “Compliance Issue” to focus only on crucial cases.
• Items with Specific Tags/Users: Migrate records assigned to a particular user or team, such as cases owned by a dedicated support group or specific sales reps.

Over the last three years, our team has lived inside APIs. We have wrestled with quirks, worked around odd limits, and learned the little tricks that make stubborn endpoints cooperate. The result is simple. Your data shows up in your destination exactly how you want it. We have run 1000+ bespoke migrations and met 99 percent of custom requirements along the way.

Step 2: Decide Entities To Migrate

Different types of platforms come with their own sets of data entities. Here’s a look at the key entities we typically work with:

Document Workspaces (e.g., Quip to SharePoint or Confluence)

• Documents and Spreadsheets
• Folders and Workspace hierarchies
• Inline comments and conversation histories
• Embedded images and attachments

CRM (Customer Relationship Management Systems)

• Contacts
• Leads
• Opportunities
• Accounts
• Activities (e.g., emails, meetings, tasks)
• Deals
• Pipelines
• Custom Fields (any additional data added by clients)

Helpdesks (e.g., Zendesk, Freshdesk)

• Tickets
• Customers/Contacts
• Agents
• Ticket Statuses and Priorities
• Categories and Tags
• Custom Fields and Macros/Automation Rules

ATS (Applicant Tracking Systems) (e.g., Greenhouse, Lever)

• Candidates
• Job Postings
• Applications
• Interviews and Feedback Notes
• Recruiters and Hiring Managers
• Custom Stages and Fields (e.g., recruitment phases)

Ticketing Platforms (e.g. Jira Service Management, Linear)

• Issues/Tickets
• Projects
• Epics and Tasks
• Assignees and Watchers
• Workflow Statuses
• Custom Fields and Labels

Step 3: Finalize the Approach

Once the scope and entities are identified, we decide the best way to migrate:

Choose Data Transfer Methods: Use APIs for direct, seamless integrations or JSON files for more complex structures that require precise handling. CSV files can also be used as a fallback, though this is usually the least preferred option due to limitations in handling complex relationships between entities.

We have discussed the pros and cons of all the three options — APIs, CSVs, and JSON, here: Using CSVs for SaaS Data Migrations: Pros and Cons

Step 4: NDA and Platform Access

• Sign a Non-Disclosure Agreement (NDA) if required by the client to ensure data security and confidentiality.
• Platform Access: Gain access to both source and destination platforms. If direct access is not possible, setting up trial accounts can facilitate the migration testing process.

Step 5: Connect Source & Destination Accounts, Analyze Data and complete 'ClonePartner Migration Checklist'

Once the necessary housekeeping and compliance steps are complete, we begin the data analysis phase. At ClonePartner, we’ve developed a specialized tool that allows companies to effortlessly connect their source and destination accounts. This tool enables us to sync the data via APIs to a temporary database, ensuring all data is gathered securely and efficiently.

After collecting all the data, we proceed with our ClonePartner Migration Checklist. This Checklist serves as our source of truth throughout the migration process. It guides the ClonePartner engineering team in executing the migration with precision and consistency, ensuring every detail aligns with the established plan.

Next, we share our findings with the client to finalize the scope of the migration. During this review, we verify all critical components—catching any missing tags, users, custom fields, or permissions that may have been overlooked. This thorough validation step ensures that everything required for a successful migration is accounted for, allowing us to move forward with full confidence that no important data is left behind.

Step 6: Sample Migration and What's Included

Before executing the complete migration, a sample migration is critical. When evaluating Quip-to-SharePoint migration tools or services, the proof of concept is where you validate data fidelity. Our standard deliverables for this phase include:

• Proof of Concept (POC): A targeted test run of your most complex records or documents.
• Unlimited Sample Migrations: We iterate on the sample set until formatting, permissions, and relationships map exactly to your requirements.
• Validation Report: A detailed breakdown of what migrated successfully, any API limitations encountered, and how we resolved them.
• Pre-Sample Migration Setup: Sync records from the source account to a temporary database, ensuring no data loss. Users are then created through the API or added manually via the UI.

Step 7: Complete Migration

Once the sample migration is validated, we perform the complete migration, ensuring all data is moved accurately, including handling deltas where required to avoid any data loss.

We typically run complete migrations over a weekend. Through the migration process, we keep the client updated on the progress and share the estimated time to completion.

Sample Timelines by Workspace Size

Migration speed depends heavily on API rate limits and data volume. For document-heavy projects like Quip to SharePoint, here are our typical timelines:

• 1–500 documents: 1–2 days
• 500–5,000 documents: 3–7 days
• 5,000+ documents: Custom engagement (often split into an initial bulk migration followed by delta syncs)

Step 8: Post-Migration Cleanup and Notification

Delete Data and Notify: After the migration is complete, data from any temporary storage is securely deleted, and the client is notified. This ensures data security and compliance with privacy guidelines.

Summing it up

At ClonePartner, our goal is to make migrations seamless, efficient, and secure. Whether your needs are complex—like syncing only specific data for different locations—or straightforward, we bring our expertise and experience to every migration project. Get in touch if you’re looking for a partner who can make migrations the easiest part of your customer onboarding journey.