Section 7 of 9

Moving in from another tool

The most common migration is not from a competitor. It is from Workfront itself, where campaign plans have been squeezed into portfolios, programs, and project custom forms for years.

In plain terms

Moving in is mostly deciding what each old piece becomes: a table in Planning, a project in Workfront, or something that stays outside. Do that mapping before exporting anything, and use the move to fix the labels everyone has been living with.

Why teams consolidate here

The plan lives in slide decks and spreadsheets while the work lives in Workfront, so nobody can answer what are we running in EMEA next quarter, for which audience, against which brand, at what budget without a manual roll-up. Campaign details trapped in project custom forms cannot be sliced across projects. Every team keeps its own list of brands and markets. Requests arrive by email.

Planning’s answer is a layer where the marketing taxonomy — brand, market, audience, channel, funnel stage — is first-class, connected to the Workfront projects that execute it. Describe it in the team’s own words; their version of the problem persuades better than the generic one.

Where each source lands

Figure 1. Where each source’s pieces land. Pick a source above; blue targets are Planning, gold are Workfront Workflow, grey are outside both.

From Workfront: lift the plan out of projects

Campaigns modeled as projects, grouped into portfolios and programs, with brand, market, audience, channel, and budget in project custom forms. The metadata moves to Planning fields, where it can be sliced across campaigns; picklists that are really entities become taxonomy record types.

Projects and templates stay exactly where they are — the templates become the automation’s target. Pick one owner per field: a value people edit on the project drifts from its Planning twin within days.

The pattern, for any source

Inventory every board, base, sheet, project type, and custom form. Surface the dead ones — migration is the cheapest moment to drop them, and usually a third can go.
Map the taxonomy before exporting anything. Decide what is a record type, a field, a connection, or a view. Do not mirror the source’s shape; apply the record-type-or-field test from section 4.
Decide the Planning and Workflow split. The step unique to this platform, and the one most often skipped. A source tool that mixed plan and execution must be separated, not transplanted.
Pick the mechanics: Planning’s CSV or Excel import (5 MB, 25,000 rows, 500 columns; 1.5 MB per API import), the Planning and Workflow APIs (OAuth 2.0 only, 200 requests per minute), Fusion connectors for a parallel run, or the source tool’s own export.
Build the structure, from a workspace template where one fits.
Import in dependency order: taxonomies first — brands, markets, audiences, channels — then operational records, then connections. Connections can only reference records that already exist, and the picker searches the primary field, so clean primary values before import.
Rebuild views, forms, and automations. Source dashboards become Planning views plus Workfront dashboards; source automations split across Planning automations, Workflow business rules, and Fusion.
Run both in parallel with an explicit cutover date.
Decommission: close licenses, archive exports, and write down what was kept and what reshaped. The first “where did X go?” arrives within a week.

From Workfront itself

The highest-value migration for existing customers, and Adobe’s own recommended direction: strategic work moves to Planning record types, and Workflow stays focused on execution.

Workfront to Planning, piece by piece.
In Workfront today	Becomes
Portfolios and programs	Initiative, Campaign, or Tactic record types. Keep the Workfront objects only if reporting or financials genuinely depend on them; Planning can connect to them for a phased retirement.
Project custom-form fields	Planning fields on Campaign or Tactic — the core of the migration. The same metadata becomes sliceable across records.
Picklists that are really entities	Taxonomy record types — Brand, Region, Product, Audience — not single-selects. This is where the payoff comes from.
“Campaign” projects used as containers	Campaign records with delivery projects connected underneath, created by automation from templates.
Projects and project templates	They stay exactly where they are. Templates become the automation’s target.

Planning fields are invisible from Workflow. Anything a project-level report truly needs must stay on the project. Inventory the reports and dashboards that read project custom fields before removing one; often the right order is populate Planning, run both for a quarter, then retire the project field.

One owner per field. A value people edit on the project drifts from its Planning twin within days. Make one side the owner and the other read-only or a lookup.

Teams that used portfolios for permissions rather than planning need a different answer: Planning sharing is its own model.

From Airtable

The closest source conceptually — the easiest map, and the most likely to carry over bad habits. Base becomes workspace; table, record type; record, record; field, field; linked record, connection; lookup and rollup, summarized lookup; formula, formula field (different syntax); view, view; form, request form; interface page, a Workfront dashboard or custom surface; automation, a Planning automation, Workflow business rule, or Fusion.

Attachment fields have no Planning equivalent. Assets go to AEM Assets or Workfront Documents. Audit the volume early — it is usually the biggest surprise.
Formulas need rewriting, and there are only 20 per record type. Prioritize.
Task-tracking tables become Workfront projects and tasks. Airtable bases usually mix plan and execution in one table; separate them.
AI fields do not exist; re-express them as Fusion scenarios writing into normal fields.
A 60,000-row table is over the 25,000-per-record-type ceiling. That data needs another home, usually the warehouse with summaries connected.

Most bases have accumulated views and fields nobody uses — inventory first. One-base-per-client agency setups map to the one-workspace-per-client decision; make it deliberately.

From spreadsheets

The most common source, the easiest import, and the easiest to under-design. One sheet rarely equals one record type: a typical campaign calendar holds a Campaigns record type plus Brands, Markets, and Channels taxonomies, flattened into columns. Split before importing, and import the taxonomies first so connections can resolve.

Merged cells, color-as-status, and comment-as-metadata all have to become typed fields. Color coding usually carries real information — ask what each color means before discarding it. Multi-value cells such as “EMEA, APAC” become multi-selects or connections, not text.

The sheet’s owner often has undocumented conventions; sit with them before importing, not after. And people used to typing anything anywhere will feel the move to typed fields and locked lists — that is the real change-management work.

From other tools

Other sources, in brief.
Source	Mapping	What reshapes
Asana	Project → Campaign or Tactic record, or a Workfront project — decide per project. Section → single-select or grouping. Task → Workfront task. Goal → an Objectives record type if OKRs matter.	Subtasks beyond two levels collapse; section-as-status becomes a real status field; inconsistent “Status” meanings get standardized.
Monday.com	Board → record type. Group → single-select. Item → record. Subitem → child record type or Workfront task. Connect-boards column → connection. Mirror column → lookup.	File columns have no equivalent; formula columns need rewriting. Consolidating 30 boards into 6 connected record types is usually the real win.
Wrike	Folder → view filter or taxonomy connection. Task → Workfront task. Custom workflow → one status single-select. Approval → Workfront approval or proofing.	Do not transplant per-folder workflows; keep the load-bearing transitions. Task dependencies map cleanly to Workfront — the target is richer.
Smartsheet	Sheet → record type, often several into one. Cell link → connection or lookup. Parent and child rows → connected record types. Dashboard → Workfront dashboard.	INDEX/MATCH becomes a lookup; SUMIFS a summarized lookup. The 20-formula cap forces priorities. Do not recreate cell-link fragility.
Trello, Notion, Basecamp, Planner	Usually the lightweight or small shape. Lists and buckets → status; labels → multi-select; checklists and to-dos → Workfront tasks; Notion relations → connections, rollups → summarized lookups.	Keep Notion’s narrative documents in Notion and link to them. Confirm the Basecamp generation before planning the export.
Jira, marketing work only	Project → view filter or single-select. Issue → Planning record or Workfront task. Epic → connected parent record.	For engineering work, integrate at the epic level instead. Re-wire submission paths to the Planning form before cutover, or intake keeps flowing into Jira for months.

After the move

Build the two or three views each audience needs, not every view the source had.
Stand up the request form and point every old intake path at it.
Wire the project-creating automation, and verify it as a normal user, not only as an administrator.
Rebuild only the automations people actually used — source tools accumulate dead rules.
Run in parallel, decommission, then write down what reshaped.

The one moment for the taxonomy

A migration is the only time an organization willingly revisits its taxonomy. Spend it on the taxonomy, not on preserving the old tool’s shape.

Do not mirror the source

Its quirks should not survive the move. Map to record types, fields, connections, and views first.

Sources

Adobe Workfront Planning documentation — terminology, request forms, automations, object limitations: Experience League article index
Planning API reference, versions 1 and 2: developer.adobe.com/wf-planning
Package contents and entitlements: Adobe Workfront product description