Project Management migration

Migrate from Runrun.it to Microsoft Project

Field-level mapping, validation, and rollback between Runrun.it and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.

Runrun.it logo

Runrun.it

Source

Microsoft Project

Destination

Microsoft Project logo

Compatibility

60%

6 of 10

objects map 1:1 between Runrun.it and Microsoft Project.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Runrun.it and Microsoft Project are fundamentally different project management paradigms. Runrun.it organizes work as Kanban cards on configurable board stages with embedded time tracking per task; Microsoft Project uses task lists with Gantt bar visualization, dependency chains, and resource leveling across a calendar timeline. This migration requires translating Runrun.it's stage-based workflow into a predecessor-successor dependency model, converting time entries logged against individual tasks into Work and Actual Work values on the equivalent Microsoft Project tasks, and reconstructing the Kanban board hierarchy as summary tasks or separate task groups. We handle the Runrun.it two-step document upload (API record creation plus S3 file push) so that attachment URLs arrive as linked resources in the destination rather than broken file references. We do not migrate Runrun.it automations, AI reports, or Kanban board configurations as code; we deliver a written inventory of these for your project manager to rebuild in Microsoft Project or Project Online. Time-entry currency and rounding alignment are resolved explicitly during transform so that reported hours are not silently changed by the destination platform's default conversion behavior.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Runrun.it logo

Runrun.it

What's pushing teams away

  • Users report glitches including unresponsive features and visual bugs that disrupt daily efficiency, appearing across multiple review platforms.
  • The lack of a native mobile application makes it difficult for remote workers to access and update tasks outside of desktop browsers.
  • Creating tasks and marking them complete requires excessive clicking, with users noting the overhead consumes time better spent on actual work.
  • Structural flexibility is limited once the platform is configured, with users unable to keep part of a team on a free plan while others upgrade.
  • Time tracking features have known issues including accuracy problems that frustrate teams relying on Runrun.it for billable hour reporting.

Choosing

Microsoft Project logo

Microsoft Project

What's pulling them in

  • Organizations already running Microsoft 365 and Azure AD adopt Microsoft PPM because it slots into existing identity, Teams, and SharePoint infrastructure without requiring a separate identity provider or SSO vendor.
  • Enterprise PMOs choose it for critical-path scheduling, baseline comparison, cross-project dependencies, and resource utilization reporting that standalone PM tools cannot replicate at this depth.
  • Project Online's integration with Power BI gives portfolio-level dashboards and cost-rollup reporting that satisfies executive governance requirements without third-party BI tooling.
  • Government, financial services, and healthcare organizations select it because FedRAMP, ISO 27001, and SOC 2 compliance certifications meet enterprise procurement requirements out of the box.
  • Large IT departments default to it as the market-leader in project portfolio management software, often driven by corporate licensing agreements that bundle it with other Microsoft 365 seats.

Object mapping

How Runrun.it objects map to Microsoft Project

Each row shows how a Runrun.it 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.

Runrun.it

Project

maps to

Microsoft Project

Project

1:1
Fully supported

Runrun.it Projects map to Microsoft Project (.mpp) files or Project Online project sites. We preserve project name, description, planned start date, and planned end date as Project Summary fields. If the Runrun.it project uses multiple Kanban stages, we create a summary task per stage in the destination to preserve the workflow structure as an outline grouping rather than a visual board.

Runrun.it

Task

maps to

Microsoft Project

Task

1:1
Fully supported

Runrun.it Tasks map to Microsoft Project tasks with Name, Start, Finish, Duration, and Priority preserved. Task status (Open, Completed) maps to Percent Complete (0% vs 100%). Due dates become Finish dates. We flag any Runrun.it tasks that have multiple assignees and generate multiple task rows in Microsoft Project, one per assignee, because MSP assigns a single resource per assignment row. Tasks without start or finish dates are set to Manually Scheduled with a note for the PM to establish the timeline post-migration.

Runrun.it

Time Entry

maps to

Microsoft Project

Task Work and Actual Work fields

1:many
Fully supported

Runrun.it time entries are separate records linked to a Task by attachable_id. We aggregate all time entries per Task and map the sum to the Microsoft Project Work field if the task has no actual progress, or to Actual Work if the task is marked complete. Duration is recalculated from Work divided by the assigned resource's Max Units and Hours Per Day setting. We handle decimal-to-minute rounding explicitly rather than allowing the destination to auto-convert, which can silently change reported hours. Time-entry currency fields in Runrun.it do not map to any native Microsoft Project field and are flagged for the PM to record in a custom field.

Runrun.it

Kanban Stage

maps to

Microsoft Project

Summary Task or Task Grouping

lossy
Fully supported

Runrun.it Kanban stages are configurable per Project. We map each distinct stage name to a Microsoft Project summary task that acts as a section header in the outline view. Tasks within the summary inherit the grouping for filtering and reporting in Microsoft Project. If the destination is Project Online or Project for the Web, stages become custom field values (Text1 or Flag fields) applied to each task for board-view grouping.

Runrun.it

User/Member

maps to

Microsoft Project

Resource

1:1
Fully supported

Runrun.it team members map to Microsoft Project Resources with Name, Initials, Type (Material or Work), and Max Units. Hourly rates from Runrun.it transfer to Standard Rate on the Resource sheet. Resources are created before any task assignment so that the Owner-to-Resource lookup is satisfied at the moment of assignment migration. If a Runrun.it user has a @runrun.it email with no equivalent in the destination Microsoft 365 tenant, the resource is created with a placeholder email and flagged for the admin to update post-migration.

Runrun.it

Document

maps to

Microsoft Project

Task Attachment or Hyperlink

1:1
Fully supported

Runrun.it documents are uploaded via a two-step flow: POSTing to /api/v1.0/tasks/:task_id/documents creates a record, then the file is pushed to an Amazon S3 presigned URL. We execute both steps and preserve the S3 URL as a hyperlink attached to the corresponding Microsoft Project task. If the S3 bucket is no longer accessible, we flag the document as a broken link in the migration report and note which tasks are affected. Native file attachments to Microsoft Project tasks are not supported via the web API; hyperlinks are the standard approach for this migration path.

Runrun.it

Attachment (URL)

maps to

Microsoft Project

Task Hyperlink

1:1
Fully supported

Runrun.it Attachments with external URLs (attachable_type = Task) migrate as hyperlinks to the Microsoft Project task's Hyperlink fields (Hyperlink, Hyperlink Address, Hyperlink SubAddress). The attachment description becomes the hyperlink label.

Runrun.it

Tag

maps to

Microsoft Project

Custom Text Field

lossy
Fully supported

Runrun.it tags stored in tags_data as an array of label strings migrate to a Microsoft Project custom Text field (Text1 or Text2 depending on field availability in the destination tier). We join multiple tags with commas as the delimiter. Tag limits in Microsoft Project are set by the field type; Text fields support up to 512 characters which covers most multi-tag scenarios.

Runrun.it

Custom Field

maps to

Microsoft Project

Custom Field

lossy
Fully supported

Runrun.it custom fields with field_label and field_type map to equivalent Microsoft Project custom fields by type. Text labels become Text fields; numeric values become Number fields; date values become Date fields. We pre-create the custom field definitions in the destination before record migration begins. Note that Project Plan 1 supports limited custom field types compared to Project Plan 3 and Project Online; we verify the destination tier during scoping and flag any unsupported field types for manual handling.

Runrun.it

Comments

maps to

Microsoft Project

Task Notes

1:1
Mapping required

Runrun.it Comments attached to Tasks migrate to the Microsoft Project task Notes field as plain text. We preserve the comment body, author name (from the User mapping), and timestamp as a formatted header line. Threaded replies are appended sequentially. The Notes field in Microsoft Project supports up to 32,000 characters which covers most comment migration scenarios.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Runrun.it logo

Runrun.it gotchas

High

Two-step document upload requires S3 coordination

Medium

No documented API rate limits

Medium

No mobile app means no mobile-only data

Low

Time tracking data requires currency and rounding alignment

Microsoft Project logo

Microsoft Project gotchas

High

Project for the web is being retired and merged into Microsoft Planner

Medium

Planner-tier portfolio features are incomplete despite Plan 5 labeling

Medium

Web app constraint controls are weaker than the Windows desktop client

High

Project requires a separate license not bundled with standard Microsoft 365

Medium

Project Online API is edition-gated and inconsistently documented

Pair-specific challenges

  • Two-step document upload requires S3 coordination

    Runrun.it uploads documents via a two-step API flow: first POSTing to /api/v1.0/tasks/:task_id/documents to create the record, then uploading the file to an Amazon S3 presigned URL. If we only migrate the document record without pushing the actual file, attachment URLs arrive as broken links in Microsoft Project. We handle both steps, verify the S3 bucket is accessible during migration scoping, and fall back to a document inventory spreadsheet if the bucket cannot be reached. Teams should confirm the S3 credentials are active before migration begins.

  • Kanban stage structure does not map to Gantt dependencies

    Runrun.it Kanban stages represent workflow columns (To Do, In Progress, Review, Done) with no explicit predecessor-successor relationships between tasks. Microsoft Project requires finish-to-start or other dependency links to calculate the project schedule and critical path. We create summary task groupings per Kanban stage and flag tasks that should have explicit predecessor links for the PM to review post-migration. Without this review, tasks appear in the correct order visually but the schedule auto-calculation may produce unrealistic compression or spreading when dependencies are absent.

  • Task constraint dates do not transfer between platforms

    Microsoft Project task constraint dates (Must Start On, Must Finish On, As Soon As Possible, As Late As Possible, Start No Earlier Than, Finish No Earlier Than, Start No Later Than, Finish No Later Than) are not preserved during import from third-party formats. Adobe Workfront documentation on MS Project field mapping confirms that constraint fields are excluded during cross-platform transfer. We map only start and finish dates; the PM must re-apply any hard constraints in Microsoft Project manually. If critical tasks have deadline constraints, we flag them in the migration inventory for priority review.

  • Microsoft Project file corruption risk on complex schedules

    Microsoft Project Professional is known to develop file corruption on complex schedules with many dependencies, overallocations, and constraint date conflicts. User reports on Microsoft Q&A document issues including constraint dates changing unexpectedly when tasks are moved, BCWP reporting as zero despite progress, and files requiring XML export-reimport to recover. We mitigate this by migrating into a fresh .mpp file (not overwriting an existing one), avoiding overlapping dependencies during import, and recommending the customer use Project Online for collaborative schedules over 500 tasks. The PM should baseline the schedule immediately after migration before any edits.

  • Time-entry currency and rounding alignment

    Runrun.it time entries include date, duration, and optional currency. When migrating to Microsoft Project's Work field (expressed in hours), we convert duration from Runrun.it's recorded unit (minutes or hours depending on project settings) and round to the nearest 15-minute increment, which is the standard billing granularity for most professional services teams. Currency values from Runrun.it do not map to any native Microsoft Project field; we preserve them in a custom Cost field for the PM to reconcile against billing records.

Migration approach

Six steps for a successful Runrun.it to Microsoft Project data migration

  1. Discovery and Runrun.it API scoping

    We audit the source Runrun.it instance via the REST API: all Projects, Tasks, Time Entries, Documents, and User records are enumerated and counted. We verify the S3 bucket credentials for document uploads and test the presigned URL flow with a sample document. We identify the full list of Kanban stage names per project and the count of tasks per stage. We extract time-entry volume, custom field definitions, and tag taxonomy. This output is a written data inventory and a confirmation of S3 access before migration planning begins.

  2. Dependency modeling and summary task design

    We review the Runrun.it task list per project and design the Microsoft Project outline structure. Kanban stages become summary task headers in the Gantt view. We identify tasks that logically depend on predecessors (e.g., a Review task following an In Progress task on the same work item) and model these as finish-to-start dependencies. We also identify tasks that should have explicit constraints for the PM to apply post-migration. The dependency model is documented and reviewed with the customer before any data is written to the destination.

  3. Time-entry aggregation and Work field calculation

    We aggregate all Runrun.it time entries per task, resolving the attachable_id to the corresponding task in the migration plan. Duration sums are converted to hours and applied to Microsoft Project Work (for tasks without actual progress) or Actual Work (for completed tasks). We apply 15-minute rounding and flag any tasks where time entries span multiple assignees, which requires generating separate assignment rows in Microsoft Project. Currency values are written to a custom Cost field.

  4. Resource provisioning and user mapping

    We create Microsoft Project Resources for every distinct Runrun.it team member, mapping name, initials, and hourly rate. Resources are created before task assignment so that OwnerId-to-Resource mapping is resolved at the moment of assignment. We run a reconciliation check against the Runrun.it user list to confirm no assignees are missing a resource record. Placeholder resources are created for any Runrun.it users whose email domain does not match the destination Microsoft 365 tenant, with a flag for the admin to update.

  5. Document migration and hyperlink attachment

    We process Runrun.it documents through the two-step flow: POST the document record to the Runrun.it API, retrieve the S3 presigned URL, push the file to S3, and then write the resulting URL as a hyperlink on the corresponding Microsoft Project task. We test the S3 access before batch processing. If any S3 presigned URLs fail or the bucket is inaccessible, we generate a document inventory spreadsheet listing each task with a broken or missing attachment for the customer to handle manually. Attachment URL descriptions are preserved as hyperlink labels.

  6. Pilot migration and schedule review

    We run a pilot migration on the smallest or least complex Runrun.it project into a new Microsoft Project file. We validate task count, dependency structure, summary task groupings, time-entry totals, resource assignments, and document hyperlinks. The customer's project manager reviews the pilot file and confirms the mapping decisions before we proceed to full migration. We adjust the dependency model and field mappings based on the pilot review and document any changes.

  7. Full production migration and baseline handoff

    We run the full production migration in project order (smallest to largest) with reconciliation reports generated after each project import. After all projects are migrated, we set the baseline in Microsoft Project and deliver the automation inventory, the Kanban-stage-to-summary-task mapping document, and the document inventory. We do not migrate Runrun.it AI reports, workflow rules, or Kanban board configurations; these are documented for the PM to rebuild as part of the Microsoft Project onboarding process.

Platform deep dives

Context on both ends of the pair

Runrun.it logo

Runrun.it

Source

Strengths

  • Integrated time tracking embedded directly into Tasks with billable hour reporting for service teams.
  • Kanban-based workflow visualization with configurable stages per Project.
  • AI-enabled productivity reports and dashboards for manager-level visibility into team performance.
  • Built by Managers for Managers, with a focus on project cost control and hour-based billing.

Weaknesses

  • No native mobile application, limiting remote access for teams without consistent desktop availability.
  • Users report visual glitches and UI bugs that disrupt daily productivity workflows.
  • Task creation and completion require excessive clicking, adding friction for high-volume users.
  • Limited structural flexibility once the platform is configured, with constraints on mixing free and paid users.
Microsoft Project logo

Microsoft Project

Destination

Strengths

  • Deep critical-path scheduling with baseline comparison and cross-project dependency tracking unmatched by lighter PM tools.
  • Native Azure AD authentication, Teams integration, and Power BI reporting sit on infrastructure enterprises already license and manage.
  • Enterprise governance controls including demand intake workflows, resource request approval, and portfolio-level capacity analysis.
  • Supports both Waterfall and Agile methodologies within the same project, accommodating hybrid delivery teams.
  • Scalable from Project Plan 1 for small teams to Project Server on-premises for regulated industries with strict data-sovereignty requirements.

Weaknesses

  • Ease-of-use scores trail the category average by a wide margin; onboarding friction frustrates new users consistently across G2 and Capterra reviews.
  • Pricing ranks 42nd of 49 tools in its category — the total cost of ownership including IT administration and training is rarely recovered for small or mid-market teams.
  • No built-in client portal, external stakeholder sharing, or proofing workflow, limiting use cases to internal PMO environments only.
  • The web interface (Project for the web / Planner Premium) has materially weaker constraint controls and resource auto-leveling than the Windows desktop client.
  • Project for the web is being consolidated into Microsoft Planner, creating uncertainty about which product tier will host project portfolio data long-term.

Complexity grading

How hard is this migration?

Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Runrun.it and Microsoft Project.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Runrun.it: Not publicly documented.

  • Data volume sensitivity

    B

    Runrun.it doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Runrun.it to Microsoft Project migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Runrun.it to Microsoft Project data migrations

Answers to the questions buyers ask most during Runrun.it to Microsoft Project migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Runrun.it to Microsoft Project migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Small migrations with fewer than 200 tasks and 3 projects typically complete in three to five weeks. Larger migrations with more than 500 tasks, multiple projects, high-volume time-entry histories, or complex Kanban stage structures requiring manual dependency review move to seven to eleven weeks. The dependency modeling and time-entry aggregation steps are the primary drivers of timeline variation.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Runrun.it.
Land in Microsoft Project, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day