Project Management migration
Field-level mapping, validation, and rollback between Stackby and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.
Stackby
Source
Microsoft Project
Destination
Compatibility
7 of 10
objects map 1:1 between Stackby and Microsoft Project.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Stackby to Microsoft Project is a structural migration from a flexible spreadsheet-database hybrid to a purpose-built project scheduling tool. Stackby's relational Tables, Rows, and 25+ column types must map into Microsoft Project's task hierarchy with Summary Tasks, subtasks, milestones, dependencies, and resource assignments. We preserve custom field values at migration time, but formula columns compute statically and Stackby's automations, integrations, and view configurations require rebuilding. Stackby's API rate limit of 5 requests per second per Stack governs migration pacing, and we scope timelines accounting for this constraint. We deliver a written inventory of active automations, view setups, and integrations requiring post-migration rebuild so the customer's team can reconstruct them in Microsoft Project.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Stackby object lands in Microsoft Project, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Stackby
Stack
Microsoft Project
Project
1:1Stackby's Stack is the top-level organizational container and maps directly to a Microsoft Project file (MPP) or Project Online Project. Each Stack becomes one project plan. We extract the Stack's name, description, and any top-level metadata fields as Project-level custom fields in Microsoft Project. If the customer uses Stackby Enterprise with multiple Stacks representing separate projects, each Stack maps to a separate Project within the destination Project Online site or Project Server workspace.
Stackby
Table
Microsoft Project
Task List
1:1Stackby Tables within a Stack map to the task list within a Microsoft Project plan. Each Table becomes a separate task list if the destination is Project Online and the customer uses multiple Project Online lists; otherwise, all Tables within a Stack merge into the single task list of one MPP file. We preserve column order from the primary Table used for project tracking, and secondary Tables with reference data (RACI matrices, risk registers) migrate as custom fields or linked records requiring manual reattachment.
Stackby
Row
Microsoft Project
Task
1:1Stackby Rows are the fundamental task records and map directly to Microsoft Project Tasks. Task Name maps from the Row's primary text field (typically the first Text column). Start Date and Finish Date migrate from Stackby Date columns (or the created_at timestamp if no date column exists). Duration, Percent Complete, and Priority migrate from corresponding Number or Select columns. We preserve the original Row ID as a custom Text field for audit traceability.
Stackby
Column: Date/DateTime
Microsoft Project
Task Start/Finish
1:1Stackby Date and DateTime columns map to Microsoft Project Start and Finish date fields. If the Stackby Table has both a Planned Date and an Actual Date column, the Planned Date maps to Start/Finish and the Actual Date maps to Actual Start/Actual Finish. All dates migrate in UTC and convert to the destination Project Online site's time zone setting during import.
Stackby
Column: Select / Multi-select
Microsoft Project
Task Custom Fields (Lookup Table)
lossyStackby Select and Multi-select columns map to Microsoft Project custom fields. Single-select options become lookup table entries on a Text custom field (Text1 through Text30); multi-select options become Text custom fields with semicolon-separated values or a custom multi-value lookup table if the destination supports it. We create the lookup table in Project Online with the same option values during schema setup, then populate Task CustomFieldValue during import.
Stackby
Column: Number (for duration/hours)
Microsoft Project
Task Duration or Work
1:1Stackby Number columns used for estimated hours, story points, or effort estimates map to Microsoft Project Duration or Work fields depending on context. If the column name contains 'hour', 'effort', 'story point', or 'person-day', we map to Work (in hours). Otherwise, we map to Duration and set the duration type to Days. We flag ambiguous cases during discovery so the customer confirms the mapping before migration.
Stackby
Column: Formula
Microsoft Project
Task Custom Field (static value at migration time)
1:1Stackby Formula columns compute dynamically and cannot migrate as live formulas because Microsoft Project does not support formula expressions on custom fields at the task level. We migrate the current computed value as a static custom field value during import. If the customer needs the formula logic preserved, we document the original Stackby formula expression so it can be recreated as a Microsoft Flow calculation or a VBA macro post-migration.
Stackby
View: Kanban
Microsoft Project
Gantt Chart with grouping
lossyStackby's Kanban view with status-based swimlanes does not map to a native Microsoft Project view. We migrate the task data (which Kanban organizes) into the Gantt Chart view. We can recreate the swimlane grouping as Task Groups by the Status custom field in Project Online, providing a visual equivalent to the Kanban board within Project's native view model. The customer may need to use Microsoft Planner or a third-party Kanban tool for a board-style interface alongside Project.
Stackby
View: Calendar
Microsoft Project
Task Calendar view
lossyStackby Calendar view organizes rows by date for timeline-based visualization. Microsoft Project's Calendar view (accessible via View > Calendar in Project Desktop) displays tasks on a monthly calendar grid. We migrate the date-carrying tasks into this view by preserving Start and Finish dates. The Calendar view is available in Project Online Plan 3 and Plan 5, and in Project Professional desktop, but not in Project Plan 1 (web-only).
Stackby
Attachments
Microsoft Project
Task Notes / Document Attachments
1:1File attachments on Stackby Rows migrate as Microsoft Project Task Notes (plain text) or as SharePoint document attachments if the destination is Project Online with a connected SharePoint library. We preserve the file name and a download link or migrate the binary to the connected SharePoint site. Plan-tier storage limits on Stackby (20GB on Business, unlimited on Enterprise) must be verified against the destination Project Online site's storage quota (5TB per tenant on most M365 commercial plans).
| Stackby | Microsoft Project | Compatibility | |
|---|---|---|---|
| Stack | Project1:1 | Fully supported | |
| Table | Task List1:1 | Fully supported | |
| Row | Task1:1 | Fully supported | |
| Column: Date/DateTime | Task Start/Finish1:1 | Fully supported | |
| Column: Select / Multi-select | Task Custom Fields (Lookup Table)lossy | Fully supported | |
| Column: Number (for duration/hours) | Task Duration or Work1:1 | Fully supported | |
| Column: Formula | Task Custom Field (static value at migration time)1:1 | Fully supported | |
| View: Kanban | Gantt Chart with groupinglossy | Fully supported | |
| View: Calendar | Task Calendar viewlossy | Fully supported | |
| Attachments | Task Notes / Document Attachments1:1 | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Stackby gotchas
API rate limit of 5 req/s per stack blocks bulk migration
Plan-tier row limits can silently truncate data
Automations and integrations do not migrate — only data does
Formula columns become static values at migration time
Attachment storage limits vary by plan and must be verified
Microsoft Project gotchas
Project for the web is being retired and merged into Microsoft Planner
Planner-tier portfolio features are incomplete despite Plan 5 labeling
Web app constraint controls are weaker than the Windows desktop client
Project requires a separate license not bundled with standard Microsoft 365
Project Online API is edition-gated and inconsistently documented
Pair-specific challenges
Migration approach
Discovery and source data audit
We audit every Stack, Table, and Column in the source Stackby workspace. This includes row counts per Table, column types (identifying Formula, Rollup, Attachment, and linked record columns), active automations, external integrations, and view configurations. We also extract attachment metadata (file names, sizes, total volume) against the destination's storage quota. The discovery output is a written migration scope document listing every object to be migrated, every column with a non-standard type requiring special handling, and every automation and integration requiring a rebuild recommendation. This document is the baseline against which the customer approves scope before migration begins.
Destination project structure design
We design the Microsoft Project destination structure in the target environment (Project Online site, Project Server, or Project Desktop file). This includes creating the Project plan with the correct fiscal year calendar, setting the default task type (Fixed Duration vs Fixed Units), and defining custom field lookup tables mapped to Stackby's Select and Multi-select options. If the customer requires a task hierarchy, we analyze any linked-record columns in Stackby that simulate parent-child relationships and design the Summary Task outline structure accordingly. The destination schema is validated in a Project Online Sandbox or test MPP file before any production data loads.
Sandbox migration and reconciliation
We run a full migration into a Project Online Sandbox (or a test MPP file for desktop destinations) using production-like data volume. The customer's project manager or PMO lead reconciles the output: task counts match the source Stacks and Tables, dates align with the original Stackby dates, custom field values match the source column values for a random sample of 30-50 tasks, and any attachments are accessible in the destination SharePoint library. We correct any mapping errors in this sandbox phase before production migration begins. This step also surfaces any ambiguous hierarchy decisions that require customer input.
Production migration with API pacing
We run production migration in phased batches: first the primary task list (all Stackby Rows as Tasks with core fields), then custom field values (using Project Online Bulk update API or CSV import for desktop MPP), then attachments (uploading to the connected SharePoint document library and linking via Project Task Hyperlink or Notes). Stackby's API rate limit of 5 req/s governs the pacing on all API calls. For Stacks exceeding 25,000 rows, we switch to CSV export/import to bypass the throttle. Each batch emits a row-count reconciliation report showing imported vs expected counts, and failed rows are queued for retry with error classification.
Cutover, validation, and automation rebuild handoff
We freeze writes to the source Stackby workspace during the final cutover window. We run a delta migration of any records modified during the migration run, then mark the destination Project plan as the system of record. We validate the final Gantt chart structure, verify that dependencies (if modeled in Stackby via linked records) are correctly set as predecessor-successor links, and confirm that resource assignments (if captured in Stackby) are mapped to Microsoft Project resource names. We deliver the Automation and Integration Inventory document to the customer's team with Power Automate flow recommendations for each Stackby automation. We do not rebuild automations in Power Automate as part of the standard migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Stackby
Source
Strengths
Weaknesses
Microsoft Project
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Stackby and Microsoft Project.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Stackby: 5 requests per second per Stack (429 response + 30-second backoff on exceedance).
Data volume sensitivity
Stackby doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Stackby to Microsoft Project migration scoping. Not seeing yours? Book a call.
Walk through your Stackby to Microsoft Project migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Stackby
Other ways to arrive at Microsoft Project
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.