Migrate from Matilda Workspace to Microsoft Project

Matilda Teamspaces define permission boundaries and contain all child objects. We map each Teamspace to a separate SharePoint Online site or Project Online workspace depending on whether the destination uses Project Plan 3/5 or Project Server SE. If the customer uses a single Microsoft 365 tenant and expects all projects to share a portfolio view, we can map multiple Teamspaces to a single site with separate folders or project plans. The mapping decision is made during discovery based on the customer's existing Microsoft 365 structure and PMO governance model.

Matilda Projects with start/end dates, status, and linked tasks map to Microsoft Project plans. Project name, description, start date, finish date, and status migrate directly. Custom properties on Matilda Projects map to enterprise custom fields in Project Online or to columns in the associated SharePoint list. We create the project in the destination site before importing tasks so that all task-to-project lookups are satisfied at insert time.

Matilda Tasks carry assignees, due dates, status, subtasks, and descriptions. We map task name, start date, finish date, duration, percent complete, priority, and assignee. Subtasks in Matilda are either flattened into a linked hierarchy with predecessor relationships in Microsoft Project or grouped as summary tasks with indent levels. The customer's admin chooses the subtask strategy during scoping.

Matilda's auto-schedule engine infers task sequencing from the dependency graph it generates. We extract the explicit dependency links Matilda exposes via API and translate them to Microsoft Project predecessor relationships (Finish-to-Start by default, with Lead/Lag time preserved where present). AI-generated inferred start dates are stored as informational notes on tasks rather than as static date values, allowing Microsoft Project's scheduling engine to recalculate from the explicit predecessor chain.

Matilda Docs are rich-text documents embedded within Projects and linked to Tasks. We export doc content as structured HTML and attach it as a Note on the related Project or Task in Microsoft Project. Links between Docs and Tasks are preserved as note references. Customers should review doc content after migration since formatting fidelity depends on the HTML structure Matilda exports.

Chat threads are integrated per-project in Matilda. We do not migrate chat threads to Microsoft Project because Project Online has no native chat-log object equivalent and no supported import path for threaded messaging. We provide a plain-text export of thread metadata and message content with timestamps as a reference file for the customer's records. This gap is surfaced in the pre-flight report before migration begins.

Matilda supports custom fields on Projects and Tasks. We inventory all custom field names, types, and values during discovery and generate a field-mapping table mapping each Matilda custom field to a Microsoft Project enterprise custom field of matching type (text, number, date, flag, or lookup). Custom fields are deployed to the destination Project Online or Project Server instance before any record import.

Matilda task assignees and project members map to Microsoft Project resource assignments. We resolve assignees by email address against the destination Microsoft 365 tenant's user directory. Resource names, email addresses, and assignment units migrate. If a Matilda user has no matching Microsoft 365 account, we flag them in the reconciliation report for the customer's admin to provision before migration resumes.

File attachments on Matilda Tasks and Docs are exported with their metadata and reattached to the corresponding Task in Project Online or to the associated SharePoint document library. We preserve the original filename, upload date, and uploader. File content is uploaded directly to SharePoint and linked from the task or project record.

Matilda's Customers CRM module is listed as coming soon with no stable schema. We do not migrate Customers records. This is surfaced in the pre-flight report and deferred until the feature reaches general availability and the schema is publicly documented.