[2026 R1] NullReferenceException on customization package import when the project customizes ASPX pages delivered by another package (works fine in 2025 R2)

Environment

• Fails on: Acumatica 2026 R1, build 26.100.0175
• Works on: Acumatica 2025 R2, build 25.201.0213
• ISV solution split into three customization packages, published in this order:

What happens

On a clean 2026 R1 instance (nothing published yet), uploading the FusionWMSOptimization package on the Customization Projects screen (SM204505) fails immediately with:

Error during file upload: Object reference not set to an instance of an object.

This happens at import time — the project is never even created, so we can't get to Publish.

Workaround that works: publish Basic and Advanced first, and only then import Optimization. After that, the import succeeds normally.

Stack trace

The browser only shows the message, but importing the exact same ZIP through POST /CustomizationApi/Import returns the full trace:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Customization.CstPageData.Save(XmlNode parent)
   at Customization.CstDocument.ExportXml(IObjectStorage src)
   at Customization.CstDocument.Copy(IObjectStorage src, IObjectStorage dest)
   at Customization.CstDbStorage.SaveDocument(CstDocument document, Boolean resetHash)
   at Customization.CstDbStorage.CreateNewProject(String name, Byte[] data, Nullable`1 level, String description)
   at Customization.CstWebsiteStorage.<ImportCustomizationProject>b__0(CustomizationResultData result)

So it fails inside CstPageData — a <Page> item, i.e. a Classic UI ASPX customization — while the project is being re-serialized to be stored in the database.

Side note for anyone reading their trace log: we also see a System.IO.FileNotFoundException for PX.Api.ContractBased.Common.XmlSerializers in the same request. That one is a red herring — it's a first-chance exception, the assembly ships in neither 2025 R2 nor 2026 R1, and it also appears on package imports that succeed.

The cross-package dependency

Our Optimization package contains <Page> (ASPX) customizations for six screens whose .aspx files it does not deliver — they are delivered by Advanced (and FR101020 also by Basic):

The pages that Optimization does deliver itself (FR201000, FR300000, FR650794) import without any problem, and so do its customizations of stock screens (IN202500, IN204500, IN304000, SO301000, SO302000, SO501000).

What we tested

We built variants of the package, each keeping exactly one <Page> item and everything else intact, and imported them one by one:

Two important controls:

1. Identical bytes. The table above was produced with the 2025 R2 build of the package uploaded to both sites. Same ZIP, same content — it imports on 2025 R2 and throws on 2026 R1. So this is not something we broke while migrating the package to 2026 R1.
2. Identical site state. Neither site had any customization published at the time, and we verified over HTTP that none of those FR screens resolve on either instance. So it is not a case of "the 2025 R2 site happened to still have the files on disk".

What we think is happening

A <Page> item is a diff against an existing .aspx in the website. Our reading of the evidence:

• In 2025 R2, importing a page diff whose base .aspx is not present in the site is tolerated — the item is stored as-is and only resolved at publish time.
• In 2026 R1, CstPageData.Save appears to try to resolve the diff against the base page while re-serializing the project into the database during import. The base page isn't there, something ends up null, and the whole import blows up.

If that's right, the implication for any ISV shipping a multi-package solution is significant: a dependency between packages that used to be implicit and only mattered at publish time has now become a hard failure at import time, and there is no message telling you which package or page is responsible.

Questions for the community

1. Has anyone else hit NullReferenceException at Customization.CstPageData.Save when importing a package on 2026 R1?
2. Is this a known regression in the 2026 R1 customization importer, or is it now intended behavior that a package can no longer carry ASPX customizations for pages delivered by a different package?
3. If it's intended, is there a supported way to declare a dependency between customization projects so the platform enforces or at least reports the required import order?
4. Any recommendation other than "publish the prerequisite packages first"? For automated CI/CD pipelines that upload all packages and then publish them, this ordering constraint is a real problem.