Migrate from .STUDIO to Microsoft Project

Each .STUDIO project maps to a Microsoft Project project. We extract project name, status (active/archived), start date, due date, and description. Budget fields from .STUDIO map to a custom currency field in Microsoft Project since no native budget field exists in Project Plan 3. Projects with null budgets are flagged during scoping for the customer to set defaults or carry as null. The project-client linkage is preserved via a custom ClientName field on the project.

Each .STUDIO task maps to a task row in Microsoft Project. We map task name, status (.STUDIO status to Microsoft Project percent complete or status flag), due date (maps to Finish date), estimated hours (maps to Work or Duration based on the task-level assignment), and custom fields. Task hierarchy in .STUDIO (parent-child task lists) maps to outline structure in Microsoft Project, with subtasks represented as child rows under summary tasks. We do not migrate .STUDIO task dependencies as predecessors unless explicit dependency data is present in the .STUDIO export schema; if absent, we document the limitation.

Microsoft Project does not have a native client or company object. We map .STUDIO client records (company name, primary contact, billing address) to a custom Enterprise Client entity that we create in the destination Microsoft environment, or to a SharePoint List attached to the project site if the customer uses Project for the web with Microsoft 365. The project-Client linkage is preserved as a lookup field on the project.

.STUDIO time entries (task_id, user_id, duration, date, notes, billable flag) have no native Microsoft Project equivalent in Project Plan 3 web. We map time entries to custom fields on tasks: TotalHoursLogged as a number custom field, and a Notes custom field carrying the concatenated time entry notes with date and user. The billable flag maps to a Yes/No custom field. Where the customer uses Project desktop or Project Online with timesheet modules, we map to Assignment Work records using the Microsoft Project COM API.

.STUDIO user accounts (name, email, role, hourly rate) map to Microsoft Project resource records. We extract all distinct owners referenced in tasks and time entries, deduplicate by email, and create resource entries in the project's resource sheet. Hourly rate maps to the resource Standard Rate field. Resources without an existing Microsoft 365 account are held in a reconciliation queue for the customer admin to provision before the production migration phase.

.STUDIO workspaces with more than 10 active custom fields require prioritization. The Microsoft Project import wizard caps custom field imports at 10 per project. We read the active .STUDIO custom field schema at export time, rank fields by business value and data population rate during scoping, and import the top 10. Remaining fields are documented in a custom field manifest so the customer's admin can add them post-migration. Formula fields and cross-field references from .STUDIO that cannot be expressed in Microsoft Project are stored as plain-text in the nearest equivalent field.

.STUDIO tags are flat string labels applied to tasks and projects. Where multiple tags exist on a single task, we split them and concatenate into a single text custom field in Microsoft Project. If the destination is Project for the web within Microsoft 365, tags may alternatively map to Planner-style labels if the customer enables that feature on the Plan. The customer chooses the tag strategy during scoping.

.STUDIO task comments (author, timestamp, text body) map to the Notes field on Microsoft Project tasks. For active collaboration environments where the project team uses Microsoft Teams, comments can alternatively be migrated as a linked Teams conversation thread on the task. We export all comments and re-associate them with the migrated task by appending each comment with its author and timestamp to the task notes field.

File attachments in .STUDIO (filename, URL, size, type) are exported as metadata only. We map attachment URLs to a custom text field on the task. If the customer's Microsoft 365 environment uses SharePoint or OneDrive for document storage, we document the recommended folder structure and the admin can manually link or relocate files post-migration. Binary file content (actual file upload) is not migrated as .STUDIO does not expose a direct file download endpoint in its API.

Project and task templates in .STUDIO are exported as structural records (blueprint data without populated task instances). We document the template structure — project name, task list layout, custom field assignments, and task hierarchy — in a written template manifest delivered to the customer admin. Templates do not migrate as reusable objects in Microsoft Project; the admin rebuilds them using Project's Save as Template function in desktop or creates new project templates in Project for the web.