Anaplan's New UX (pages organized into apps, with boards, worksheets, and reports) has been the platform's primary interface for years, and it is where all new front-end features ship. Plenty of production models still run on Classic dashboards, because the dashboards work and migration has never made it to the top of the list. Here is how to move without making planners' lives worse for a quarter.
Step 1: Inventory what you actually have
Export the list of Classic dashboards, then for each one record:
- Who uses it (by role), how often, and for what step of which process.
- What is on it: grids, charts, line-item inputs, text, images, action buttons.
- Which model views and saved views it depends on.
- Whether it still works. Many old dashboards reference modules that have since changed, and some are simply abandoned.
A typical estate of 60 dashboards reduces to 25 to 35 that matter. Retire the rest rather than migrating them; the migration is the best chance you will get to do that.
Step 2: Map each dashboard to a New UX page type
The New UX has distinct page types, and the mapping is not one-to-one.
| Classic dashboard pattern | New UX target |
|---|---|
| Status overview with several grids and charts | Board with cards and a page selector |
| Single large input grid for a planner | Worksheet with a main grid and context cards (prior year, variance, comments) |
| Printable monthly pack or management report | Report page (management reporting) |
| Landing page with links and instructions | Board with text cards and page links, or the app home |
| A dashboard that is really three processes in one | Split into three pages in the same app |
Worksheets are the workhorse for data entry. Boards are for monitoring and navigation. Reports are for formatted output. Putting an input grid on a board because that is how the dashboard looked is the most common mistake.
Step 3: Design the app, not just the pages
The New UX organizes pages into apps. Decide the app structure before you build:
- One app per business process (Budget, Demand Planning, Workforce), not per model.
- Pages in process order, with a landing board explaining the steps.
- Role-based page visibility so a cost center manager sees three pages, not thirty.
- Consistent page selectors (the same list selectors in the same position on every page).
A good app has a navigation story a new user can follow without training. A migrated dashboard collection rarely does.
Step 4: Quick wins that pay for the project
Each page you rebuild is a chance to fix what the Classic dashboard could not:
- Context cards beside a worksheet grid, showing prior-year actuals, targets, and variance without scrolling.
- Conditional formatting on the grid so exceptions jump out.
- Charts that use the New UX chart types (waterfall, combination) instead of grids masquerading as charts.
- Actions placed where the step happens, with clear labels, instead of a row of buttons at the top of the page.
- Filters driven by Boolean line items from System modules, so the page shows a manager only the cost centers they own.
- Text cards with instructions replacing the paragraph of text someone pasted into a dashboard in 2018.
Resist the urge to add new functionality beyond this. Scope creep is what turns a six-week UX migration into a six-month rebuild.
Step 5: Build, test, and keep the old dashboards available
Build the pages in the production model (pages are not structural, so Application Lifecycle Management does not need to move them), or in a development model if your process requires it. Then:
- Run a side-by-side test with three to five representative users per role on real data, for one real process step. Watch them; do not just ask.
- Fix what they stumble over. It will be page selectors and grid layout, not logic.
- Keep Classic dashboards accessible but not promoted for one full planning cycle. Nobody should be blocked because a page is missing.
- Remove Classic access only when the new pages have survived a cycle.
Step 6: Communicate like a product launch
The difference between a migration that lands and one that generates a year of complaints is almost entirely communication.
- Announce the change a month ahead with screenshots of the new pages and a one-line reason ("faster, fewer clicks, works on the iPad").
- Publish a one-page guide per role: where your pages are, what changed, who to ask.
- Run two 30-minute sessions per role during the first cycle. Record them.
- Name a champion per department who gets early access and answers peers' questions.
- Collect feedback in the app (a comments grid on the landing board works fine) and visibly act on it.
Common pitfalls
- Migrating page-for-page. The goal is a usable app, not a replica. Measure success by task time and error rate, not by dashboard count.
- Ignoring mobile. New UX pages work on tablets and phones; Classic never did. Sales and field users will notice, so design the pages they use for small screens.
- Forgetting saved views. Pages are built on module views. Clean up the views you depend on, name them clearly, and do not let pages sit on "Default View" with filters applied by hand.
- Skipping the retirement. If the old dashboards stay forever, half the organization will never move.
Timeline
For a model with 30 dashboards that matter, plan six to ten weeks: one week of inventory and design, four to six of build and testing, and the remainder for rollout across one planning cycle. Our Anaplan Dashboard Development service runs this as a fixed-scope engagement, and the UX migration is also the first phase of our Platform Migrations and Modernization service.