New SQL Server 2022 slower than old 2014 server

I'm planning and testing a new SQL Server 2022 install to migrate from an older 2014 database. I've noticed during performance testing some major discrepancies with some bulky queries. Here is a query I use for testing: INSERT INTO @volume SELECT max(SUBSTRING(dbo.CLEACUM.TRADE_DATE, 1, 4)) AS TRADEYEAR, sum(CASE [CANCEL] WHEN '1' THEN - cast(abs([TOT_QTY]) as bigint) ELSE cast(abs([TOT_QTY]) as bigint) END) AS TOT_QTY,0 FROM dbo.CLEACUM LEFT OUTER JOIN dbo.IBM_SECMASTER ON dbo.CLEACUM.TDE_SYMBOL = dbo.IBM_SECMASTER.DCS_CUSIP LEFT OUTER JOIN dbo.VOL_IBM_CODES_IDA ON dbo.IBM_SECMASTER.SEC_CLASS >= dbo.VOL_IBM_CODES_IDA.NUMMIN AND dbo.IBM_SECMASTER.SEC_CLASS = dbo.VOL_IBM_CODES_IDA.TYPEMIN AND dbo.IBM_SECMASTER.SEC_TYPE = ABS(CONVERT(float, DATEDIFF(day, dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE) / 365.25)) AND dbo.VOL_IBM_CODES_IDA.DATEMIN = ABS(CONVERT(float, DATEDIFF(day, dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE) / 365.25)) AND dbo.VOL_MaturityLabels.DATEMIN datepart(yyyy,getdate())-5) and (cast(TRADE_DATE as date)<= VOLUME_SAME_PERIOD_DAY) group by SUBSTRING(dbo.CLEACUM.TRADE_DATE, 1, 4) The CLEACUM table is quite big. Around 17M rows over 3.2GB disk space. Nothing insane but still big for such a query to scan the whole table. When I run on 2014, fresh start or live for days, the query completes at max 30sec. When I run on 2022, it takes over 50 mins to complete. Next run will run complete in 30sec. The DBCC DROPCLEANBUFFERS command will also make it run slow again without a restart or a long wait. From troubleshooting, I can see the IO loading the table from disk (reading ~1MB from mdf file), which I assume is the delay and the subsequent run will use data from cache instead. I'm ok with that but... How is 2014 not doing the same thing? If I run that same query on 2014 after a machine reboot, it still runs in 30s or less! But in 2022 it needs to load it from disk before it can use the cache. Both give me about the same stats when measured: Table '#B59594BD'. Scan count 0, logical reads 5, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'VOL_MaturityLabels'. Scan count 1, logical reads 192958, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 1746, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Workfile'. Scan count 14, logical reads 2872, physical reads 338, read-ahead reads 2534, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'VOL_CUSIPEquivalence'. Scan count 1, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'VOL_IBM_CODES_IDA'. Scan count 1, logical reads 1736622, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'IBM_SECMASTER'. Scan count 1, logical reads 65, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'VOL_ExcludedAccounts'. Scan count 1, logical reads 195636, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'CLEACUM'. Scan count 1, logical reads 1040096, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'VOL_BusinessDaysPerYear'. Scan count 1, logical reads 1, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. SQL Server Execution Times: CPU time = 24008 ms, elapsed time = 28572 ms. Table '#AAEDD858'. Scan count 0, logical reads 5, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'VOL_MaturityLabels'. Scan count 1, logical reads 192958, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, page server reads 0, read-ahead reads 1746, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'Workfile'. Scan count 14, logical reads 2872, physical reads 338, page server reads 0, read-ahead reads 2534, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'VOL_CUSIPEquivalence'. Scan count 1, logical reads 8, physical reads 5, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'VOL_IBM_CODES_IDA'. Scan count 1, logical reads 1736622, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'IBM_SECMASTER'. Scan count 1, logical reads 65, physical reads 0, page server reads 0, read-ahead reads 88, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'VOL_ExcludedAccounts'. Scan count 1, logical reads 195636, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'CLEACUM'. Scan count 1, logical reads 1040096, physical reads 17904, page server reads 0, read-ahead reads 305712, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. Table 'VOL_BusinessDaysPerYear'. Scan count 1, logical reads 1, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. SQL Server Execution Times: CPU time = 40063 ms, elapsed time = 3041555 ms. For context, both essentially run on same hypervisor/storage with both VMs configured with identical resources. Original server had no index of any kind and OLTP wasn't a thing with 2014 (nor is it enabled in our 2022). The HA feature is configured on 2022 but the concerned DB isn't replicated yet. I made both as identical as possible to limit variables. Only difference I noticed is 2014 will allocate all max mem (16GB) for SQL right away at launch whereas 2022 seems to be more dynamic depending on queries. I know the query isn't optimal, but my job is just to migrate it all on a newer server. What am I missing, not understanding? How can I achieve the same level of performance on 2022 as our current 2014? Execution plan 2014 and 2022 --- Session wait stats are all PAGEIOLATCH_SH (my interpretation is waiting on IO for data to continue, which matches IO stats). I set memory reservation on VM and rebooted. Still no change, not even a second in difference.