Migrating From SharePoint to Papyrus — A 90-Day Plan
A pragmatic, week-by-week migration plan from Microsoft SharePoint to Papyrus, with the rough edges flagged.
Migrating From SharePoint to Papyrus — A 90-Day Plan
SharePoint migrations are rarely just file moves. They're behaviour migrations — the way teams work needs to shift. This is a 90-day plan that respects that.
The pre-conditions
Before you start, confirm:
- You have an executive sponsor (a CIO or COO who'll pick the bills and the political fights)
- You have a Records Officer or equivalent for the content side
- You have a SharePoint admin who can help with exports
- Papyrus is provisioned, billing is set up, your domain is configured
If any of these are missing, fix them first. The migration will fail without them.
Days 1-7 — Discovery
What's actually in your SharePoint?
- Total document count (per site collection)
- Total storage volume
- Document type distribution
- Permission complexity (how many unique groups, how deep the inheritance)
- Active vs dormant content (last-touch date histogram)
- Custom columns and metadata
- Workflows in flight (SharePoint Designer or Power Automate)
- Integrations (the SharePoint sites that other systems pull from)
This is unglamorous archaeology. Three days minimum.
Days 8-14 — Decide what doesn't come
Migrations fail when they try to bring everything. Decide what doesn't come:
- Dormant content (last touched >24 months ago): typically 60-70% of volume. Move to cold archive, not to Papyrus
- Personal sites (
My Sites): don't migrate; users export their own keepers - Duplicate content: SharePoint duplicates 40-50% of content; let Papyrus's deduplication catch the rest
- Test sites and abandoned project sites: archive, don't migrate
After this exercise, you'll typically migrate 20-30% of your SharePoint volume to Papyrus. That's a feature, not a bug.
Days 15-21 — Map structure
For the content that is coming, decide the target structure in Papyrus:
- Departments (Papyrus's top-level scoping)
- Folder hierarchy (Papyrus prefers flat; resist deep folder trees)
- Classifications (your AI-categorisation taxonomy)
- Tags (where SharePoint columns become Papyrus tags)
- Permissions (translated from SharePoint's group model)
Don't recreate SharePoint's structure in Papyrus. That's a missed opportunity.
Days 22-35 — Run the export
SharePoint exports run via the Migration API or third-party tools (ShareGate, Metalogix). Plan:
- Throttling: Microsoft throttles exports; budget 2-3× your naive estimate
- Format: export to a portable format (PDF for finalised content, original Office formats for editable)
- Metadata: capture every SharePoint column you've decided to keep
Export to staging storage; do not point exports directly at Papyrus.
Days 36-50 — Ingest in waves
Ingest one department at a time. For each:
- Upload a sample (50-100 documents)
- Verify classification and extraction accuracy
- Adjust the classification configuration if needed
- Bulk ingest the rest
- Spot-check the result
A typical wave takes 1-2 days per 10K documents. The bottleneck is usually QA, not throughput.
Days 51-65 — Permissions and access
Translate SharePoint's permission model to Papyrus's:
- SharePoint groups → Papyrus roles + departments
- Site-level permissions → folder-level permissions
- Document-level overrides → preserved as Papyrus document permissions
This is the most labour-intensive phase. Plan for 2 weeks.
SharePoint permissions tend to accumulate over years. When in doubt, open up rather than lock down — users complaining they can't access something is recoverable; users finding something they shouldn't is not.
SharePoint workflows (Designer, Power Automate) translate to Papyrus workflow templates. For each in-flight workflow:
- Identify the trigger (document upload, status change, scheduled)
- Identify the actions (approval, notification, route)
- Reproduce in the Papyrus workflow designer
- Test with a sample document
Some Power Automate workflows that span multiple systems are best left in Power Automate, calling Papyrus's REST API where they need document operations.
Days 76-85 — Behaviour migration
Now talk to humans. The technical migration is done; behaviour change starts here.
- Lunch-and-learn sessions per department
- “How I find things” walkthrough (SharePoint folder browsing → Papyrus search)
- “How I share things” walkthrough (SharePoint share dialog → Papyrus share link)
- “How I get approvals” walkthrough (Power Automate notification → Papyrus workflow task)
- Champions in each department who answer questions for the first month
Days 86-90 — Cutover
Sequenced cutover:
- Day 86: New uploads to Papyrus only (SharePoint becomes read-only for new content)
- Day 88: Active workflows in SharePoint completed; new workflows in Papyrus only
- Day 90: SharePoint cold-archived; primary access via Papyrus
After 90 days
Don't decommission SharePoint immediately. Keep it as a cold archive for 12 months. After 12 months without access, decommission.
What goes wrong
The classic SharePoint-to-Papyrus migration failure modes:
- Tried to migrate everything: 18-month project that loses sponsor support
- Recreated SharePoint structure: defeats the purpose of moving
- Skipped behaviour change: users keep working in SharePoint via web access
- No champion network: questions accumulate, frustration builds, adoption stalls
The fix to all four is in the planning, not the execution.