Migrate Financial Baseline to the Next Experience - very bad performance

[Attila Beregvar]

Hello Community,

I would be interested in your experience with the standard migration job "Migrate Financial Baselines to the Next Experience". I was running this job for smaller-bigger batches recently as part of our overall migration activities to the new project workspace, and the performance seems to be extremely bad.

I know that the overall performance can be affected by many factors (number of projects, cost plan breakdowns, expense line, any other related data), but I have seen cases where this job was running 10+ HOURS on a batch of 100 project records, and within that 10 hours it only made 44K SQL statements - that is surprisingly low.

How is your experience with this job?

[phil_bool_unifi]

That's an interesting insight.  I've not used this tool to migrate particularly large records.  I appreciate that baselines contain a good deal of information, but I'm amazed if there are 40,000 data points in any of them. 

Have you customised the baseline records at all, by adding additional fields or logic?  If you have, these may be the issue.  It might be worth reviewing the value of those customisations, and seeing if any can be reverted.

Have you also checked how many baseline records are present for the project?  Is it possible that they've accidentally been multiplied by any previous scripts?

If not, I would definitely check if there are any updates available for the SPM products you've got installed (although I doubt that will make much difference) and if not, or if these don't make a difference, raise a support ticket.   It's likely you're not the only one affected, although the scale of impact may be less for the majority of customers. 

[Attila Beregvar]

Hello Phil, thanks for taking the time to reply!

Maybe I wasn't expressing the situation around the SQL statements clearly, what I meant was that I've checked the progress worker for the scheduled job, which was running for 10+ hours, and under that 10 hours, the overall amount of SQL statements the process has done was ~44k. This is a very low number, under this time this should be in the millions if not tens of millions.

I've checked the batch size, and 100 projects had around ~1700 financial baselines to be migrated, and we dont have any custom information saved in the baselines. There are cases where the baselines has huge cost plans, going on for multiple years, but this alone cannot explain why the process this slow.

Reaching out to the official support might be the next step, but I wanted to get some inputs from the community first:)

[Dheeraj Bharsiy]

Hi Attila,

Thanks for sharing the details. 44K SQL statements in 10+ hours is indeed very low throughput for 1700 baselines — it suggests the process is spending most of its time waiting rather than actively processing.

To give some context on what the migration does:

it creates new investment baseline records and then updates the existing cost/benefit plan baseline records (which already exist from when the baseline was originally taken). The updates include calculating actuals from the fm_expense_line table for each fiscal period. Note that investment currency field population (if multi-currency is enabled) was only added in the Q1 release of Financials Core, so if you're on an earlier version, that wouldn't be a factor.

For baselines with cost plans spanning multiple years, there can be many cost_plan_breakdown_baseline records to update — but even so, this shouldn't take 10+ hours for your data volume.

A few things worth checking:

• Other scheduled jobs: Were any other heavy jobs or migrations running at the same time? Competing processes can cause the database to slow down significantly

• System logs: Check syslog and transaction logs around the time of execution for any slow query warnings or signs that the process was being throttled or queued

• ACLs on related tables: If there are custom or restrictive ACLs on financial tables (particularly fm_expense_line), the ACL evaluation overhead on each record access can add up significantly and slow down the migration

I'd recommend raising a case with ServiceNow Support — support team can review instance-level diagnostics (transaction logs, database performance, resource usage) during the migration window, which would help pinpoint the actual bottleneck