Migrate from Deltek WorkBook to Microsoft Project

Deltek WorkBook Projects map directly to Microsoft Project as the top-level container. Project name, start date, finish date, status, and budget total migrate. WorkBook project templates map to Project's template format (.mpt for desktop, Project Online template library). Multi-company WorkBook configurations that reference separate legal entities require separate Project Online sites or separate MPP files per entity. Project-level custom fields migrate to Project-level custom fields in Project Online or outline codes in desktop MPP.

WorkBook Tasks map to Microsoft Project Tasks with the WBS hierarchy preserved as parent-child outline levels. Task name, start and finish dates, duration, % complete, priority, and notes migrate. WorkBook's Kanban-status (To Do, In Progress, Done) maps to a custom text field or Task Status picklist in Project since Project uses % complete and duration-based scheduling rather than Kanban states. Predecessor relationships from WorkBook's task dependencies map to Project predecessor fields. Subtasks with independent scheduling in WorkBook map as summary tasks or as separate tasks with a parent reference.

WorkBook Workers (team members with skills, availability, and utilisation data) map to Microsoft Project resources. Max Units and Standard Rate migrate from WorkBook's hourly cost and capacity. WorkBook skills and certifications have no direct Project equivalent — we map skill tags to a Resource custom field (text, multi-value) so that the information is preserved. WorkBook's availability calendars migrate as Project resource calendars, with calendar exceptions for holidays and planned time off carried forward. Generic resources in WorkBook map to generic resources in Project.

WorkBook's resource assignments against tasks (which worker is assigned to which task with what hourly rate) map to Project Assignments. WorkBook's assigned hours migrate as Assignment Work (hours), WorkBook's task budget hours migrate as Assignment Units. The Work (hours) field drives Project's scheduling calculation against the resource's calendar and Max Units.

WorkBook time entries against Projects and Tasks aggregate into Project Assignment Actual Work. Since Project does not have a dedicated timesheet ledger, we summarise WorkBook's submitted and approved hours by task-assignment pair and write them as Assignment Actual Work values. Historical time-entry timestamps and billable/non-billable flags migrate as custom fields on the Assignment. Time-entry approval status does not migrate — Project does not have an approval workflow engine for timesheets. Unapproved time entries migrate as Actual Work with a note that they require re-approval post-migration.

WorkBook CRM Contacts have no native Microsoft Project equivalent — Project stores resources (people), not contact records. We offer two migration strategies: (1) map contacts to a SharePoint Contacts list in the associated Project Online site, preserving name, email, and company; or (2) add a Contact custom field on tasks that references the WorkBook contact name for audit. The customer chooses the strategy at scoping. WorkBook contact-to-project relationships migrate as a Contact custom field on the Project.

WorkBook CRM Companies map to a SharePoint list in Project Online or to a Company custom field on Projects, depending on the customer's choice made at scoping. Microsoft Project does not have an Account or Company object, so this is a configuration migration rather than a native object migration. Company billing rates and industry tags from WorkBook do not have Project equivalents and are documented in the handoff inventory.

WorkBook pipeline stages and opportunity data are CRM objects that have no Microsoft Project equivalent. Project has no pipeline, deal stage, win/loss, or probability model. We flag this as a scope boundary: pipeline and opportunity data do not migrate. We extract the data as a structured CSV and deliver it to the customer as a reference document for manual re-entry or for import into a separate CRM if they adopt one post-migration.

WorkBook's financial module (invoices, accounts receivable, accounts payable, payment status, AR ageing, subscription billing) has no Microsoft Project equivalent. Project has no accounting ledger, no invoicing, no AR/AP, and no financial reconciliation model. We do not migrate financial records. We export a snapshot of outstanding AR, open invoices, and WIP as a structured CSV for the customer's finance team to reconcile in their chosen accounting system.

WorkBook's Chart of Accounts with 21 built-in Dimensions and up to 10 custom Dimensions (31 total per transaction) cannot map to Microsoft Project. Project has no chart of accounts, no journal entries, no cost centres, and no multi-dimensional tagging model. WorkBook Dimensions tagged against Projects and Tasks require a customer-defined strategy for how to handle cost attribution in the absence of a dimensional accounting system. We deliver a Dimension-mapping matrix documenting each WorkBook dimension label and its current usage, leaving the mapping decision to the customer.

WorkBook Purchase Orders tied to Projects and Vendors have no Microsoft Project equivalent. Project has no purchasing, vendor commitment, or PO lifecycle model. We export open PO data as a structured CSV for the customer's finance team.

WorkBook System Variables and Company Variables (numbering sequences, workflow flags, integration settings, configuration flags) are platform-specific configuration that cannot map to any Microsoft Project object. We extract these as a structured JSON bundle during the technical audit and hand them to the customer for manual review. Any variable that references a migrated record ID is flagged in the bundle.