Project Management migration
Field-level mapping, validation, and rollback between Avaza and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.
Avaza
Source
Microsoft Project
Destination
Compatibility
8 of 12
objects map 1:1 between Avaza and Microsoft Project.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Avaza to Microsoft Project is a scheduling-focused migration, not a full platform transfer. Avaza bundles project management with time tracking, expense management, and invoicing; Microsoft Project is primarily a scheduling engine built around Tasks, Resources, and Assignments. We migrate the task and resource layers 1:1 and document the financial layer (Invoices, Expenses, Billable Rates) as out-of-scope for the native Microsoft Project file because those objects have no standard destination. We handle Avaza's role-restricted rate fields by reconstructing values from the frozen timesheet record, preserve the task hierarchy through WBS-level mapping, and handle the export via XML where the API endpoint is available or via structured CSV where it is not. Team Chat history is not migratable under any export method and is explicitly scoped out of the Statement of Work.
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 Avaza 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.
Avaza
Project
Microsoft Project
Project File (MPP) or Project Online Project
1:1Avaza Projects map 1:1 to Microsoft Project files or Project Online project records. Each Avaza Project carries billing method, budget, cost rate, and billable rate inherited from the contact or timesheet category level. We migrate Project Name, start date, end date, status, and description. Budget and billing rate values transfer to custom fields in Microsoft Project because no native equivalent exists on the standard Project table. If the destination is Microsoft Project Online (Plan 3 or Plan 5 required for PWA), we provision the project via the REST API with enterprise project type and enterprise custom fields populated from Avaza project metadata.
Avaza
Section
Microsoft Project
Summary Task (WBS parent row)
1:manyAvaza Sections are grouping containers inside a Project used to organize Tasks. They carry display order but no independent metadata. We map each Section to a Microsoft Project Summary Task (a parent row at WBS level 1) with the section name as the task name and no duration. Child Tasks inherit the Summary Task as their parent. This preserves the grouping structure that Avaza users rely on for organizing work by phase or workstream.
Avaza
Task
Microsoft Project
Task (with WBS levels)
1:1Avaza Tasks map directly to Microsoft Project Tasks. We preserve task name, assignees, due dates, priorities, and flat-rate amounts (mapped to custom Cost fields in Microsoft Project). Milestone tasks in Avaza (tasks with zero duration) become Microsoft Project milestone tasks. Task dependencies in Avaza map to Predecessor links in Microsoft Project using FS, SS, SF, and FF dependency types determined by the task relationship context. If Avaza task-level custom fields are present, we map them to Project Online enterprise custom fields or MPP custom fields depending on the destination version.
Avaza
User / Team Member
Microsoft Project
Resource
1:1Avaza users (Project Collaborators, Timesheet Users, Admin/Finance Users, Resource Schedulers) map to Microsoft Project Resources. We map display name to Resource Name, email to Resource Initials or email field, and default billable rate from the contact-level rate configuration. Microsoft Project distinguishes between Material Resources (consumables) and Work Resources (people), and supports Generic Resources for unassigned capacity. We default all Avaza users to Work Resources and set Max Units based on the user's Avaza timesheet category allocation where available.
Avaza
Timesheet Category
Microsoft Project
Resource Rate Table
1:1Avaza Timesheet Categories define work types and carry default billable and cost rates that cascade into projects and timesheet entries. We map each category to a Microsoft Project Resource Cost Rate Table entry (Cost Rate A) so that when assignments are made in the destination, the correct rate applies. Multi-tier cost rates (A through E) in Microsoft Project map from Avaza's category-level rate tiers where they exist.
Avaza
Timesheet Entry
Microsoft Project
Assignment Actual Work
lossyAvaza timesheet entries are linked to a project, section, task, user, and timesheet category, and carry the Billable Rate and Cost Rate frozen at entry time. We map each timesheet entry to a Microsoft Project Assignment on the matching task-resource pair with Actual Work set to the hours logged and Actual Cost calculated from the frozen rate. This preserves historical billing data inside the project schedule. Note: Microsoft Project desktop has no native timesheet UI; the Actual Work values are stored in the file and visible in the Task Usage and Resource Usage views.
Avaza
Expense
Microsoft Project
Custom Field / No native equivalent
1:1Avaza Expenses carry amount, currency, category, billable flag, and receipt attachments linked to a project. Microsoft Project has no native expense module. We document the full expense inventory in a structured CSV delivered alongside the MPP file or Project Online migration, with project name, expense category, amount, currency, and billable flag. The customer assigns expenses to project cost baselines in Microsoft Project manually or via a separate expense tracking process. Receipt attachments migrate as file links where a reachable URL is present in the Avaza export.
Avaza
Invoice
Microsoft Project
No native equivalent
1:1Avaza Invoices can include free-form line items, uninvoiced timesheet blocks, uninvoiced expenses, and task fixed amounts, each referencing the customer. Microsoft Project has no invoice or billing module. We export invoice data as a structured document with project reference, line item breakdown, totals, currency, and payment status, delivered as a supplementary record set. The customer's finance team reconciles this against their accounting system post-migration. We use the Avaza Invoice Detail report to capture fully assembled invoice state rather than re-aggregating source records post-migration.
Avaza
Customer / External Contact
Microsoft Project
SharePoint Contact List or Dynamics 365 (if integrated)
1:1Avaza Customers (billing contacts) and External Contacts (collaborators and client portal users) carry billing and payment-term settings. Microsoft Project has no native contact management layer. If the destination is Microsoft Project Online with SharePoint, we export contacts to the associated SharePoint site contact list. If the organization uses Microsoft Dynamics 365 Sales or Customer Service, we map Avaza contacts to the corresponding Dynamics records via the customer-provided integration. Standalone MPP file destinations receive a contact CSV as a supplementary deliverable.
Avaza
Quote / Estimate
Microsoft Project
No native equivalent
1:1Avaza Quotes are distinct from invoices with approval statuses and client-view links. Avaza can convert a quote to a project in one click, but the quote itself is not a sub-object of the project. We reconstruct quote line items as a structured CSV with project reference, client name, approval status, and total value. The quote-to-project conversion history is documented in the migration inventory for the customer's project manager to reference during project initiation in Microsoft Project.
Avaza
Custom Field (Project-level)
Microsoft Project
Enterprise Custom Field (Project Online) or Custom Field (MPP)
lossyAvaza custom fields on projects appear only in filtered report views and require the correct filter context to export. We map named custom fields to Microsoft Project Enterprise Custom Fields (for Project Online destinations) or text/number/date custom fields on the Project Summary Task (for MPP file destinations). Each field requires field-by-field review during scoping because Avaza surfaces project-level custom fields inconsistently across export views.
Avaza
Custom Field (Task-level)
Microsoft Project
Task Custom Field (Project Online) or Custom Field (MPP)
lossyAvaza task-level custom fields migrate to Microsoft Project Task Custom Fields. We map text fields to Text fields, number fields to Number fields, and date fields to Date fields. Flag fields map to Flag custom fields. Task custom fields appear in the Task Details view in Project Online and in the Custom Fields column in desktop MPP.
| Avaza | Microsoft Project | Compatibility | |
|---|---|---|---|
| Project | Project File (MPP) or Project Online Project1:1 | Fully supported | |
| Section | Summary Task (WBS parent row)1:many | Fully supported | |
| Task | Task (with WBS levels)1:1 | Fully supported | |
| User / Team Member | Resource1:1 | Fully supported | |
| Timesheet Category | Resource Rate Table1:1 | Fully supported | |
| Timesheet Entry | Assignment Actual Worklossy | Fully supported | |
| Expense | Custom Field / No native equivalent1:1 | Fully supported | |
| Invoice | No native equivalent1:1 | Fully supported | |
| Customer / External Contact | SharePoint Contact List or Dynamics 365 (if integrated)1:1 | Fully supported | |
| Quote / Estimate | No native equivalent1:1 | Fully supported | |
| Custom Field (Project-level) | Enterprise Custom Field (Project Online) or Custom Field (MPP)lossy | Fully supported | |
| Custom Field (Task-level) | Task Custom Field (Project Online) or Custom Field (MPP)lossy | Fully supported |
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.
Avaza gotchas
Cost Rates and Billable Rates are role-restricted
Timesheet rate values are copied at entry time
Invoice data spans multiple linked entities
Tier-based limits on active projects and users
Team Chat has no export capability
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
Scoping and source audit
We audit the Avaza source account across Projects, Sections, Tasks, Timesheets, Expenses, Invoices, Users, and Timesheet Categories. We confirm the migration account has Admin-level credentials to ensure Cost and Billable Rates are visible in export. We identify any active project template usage, cross-project task dependencies, and the volume of timesheet entries and expenses per project. We also confirm the destination: Microsoft Project desktop (MPP), Project Online with PWA, or Project for the Web.
Destination provisioning and schema design
For Microsoft Project Online destinations, we provision the project in PWA or Project for the Web via the REST API, configure enterprise custom fields to match the named Avaza custom fields, and set up the resource pool mapping Avaza users to Project Resources with rate tables populated from Timesheet Categories. For desktop MPP destinations, we design the custom field schema on the Project Summary Task and task-level custom fields that will carry Avaza financial metadata. We document the out-of-scope objects (Invoices, Expenses, Quotes) and define the supplementary CSV export structure for each.
Rate reconstruction and timesheet aggregation
We extract all timesheet entries and reconstruct the frozen Billable Rate and Cost Rate for each entry by matching against the contact or category-level source record where direct rate export was unavailable. We aggregate timesheet hours by task-resource pair to populate Assignment Actual Work and Actual Cost in Microsoft Project. We produce a timesheet summary report alongside the migration for the customer's project manager to validate against source records.
Task hierarchy and dependency mapping
We build the WBS structure in Microsoft Project by mapping Avaza Sections to Summary Tasks and Avaza Tasks to child rows. We map Avaza task dependencies (extracted from the Avaza task relationship model) to Microsoft Project predecessor links with the appropriate dependency type (Finish-to-Start by default). We validate the imported task count, section count, and dependency count against the Avaza source export before declaring the hierarchy migration complete.
Resource pool and rate table population
We migrate Avaza users to Microsoft Project Resources, mapping display name, email, and max units. We populate the Cost Rate Table from Avaza Timesheet Categories. For users with different rates across project types (from category-level configuration), we create multiple rate table rows (A through E) in Microsoft Project and document which row applies to which project context. Resource Sheet validation confirms that all tasks with assignees have a corresponding resource before the final MPP file is saved.
Financial layer export and handoff
We export Avaza Expenses as a structured CSV with project reference, category, amount, currency, billable flag, and receipt URL where available. We export Invoices using the Invoice Detail report to capture fully assembled invoice state, delivered as a supplementary document. We deliver both alongside the migrated project file or Project Online migration with a reconciliation guide explaining how to incorporate the data into Microsoft Project cost baselines or external financial systems.
Cutover, validation, and handoff documentation
We freeze Avaza writes during the cutover window and run a final delta migration capturing any records modified since the initial export. We deliver the final MPP file or confirm Project Online project records are published, along with the financial CSV exports and a migration inventory document listing all objects migrated, out-of-scope objects, and any manual steps required. We do not rebuild Avaza automations or templates in Microsoft Project; those are documented as an admin-rebuild scope outside the migration engagement.
Platform deep dives
Avaza
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 Avaza 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
Avaza: Not publicly documented.
Data volume sensitivity
Avaza exposes a bulk API — large-volume migrations stream efficiently.
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 Avaza to Microsoft Project migration scoping. Not seeing yours? Book a call.
Walk through your Avaza 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 Avaza
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.