Skip to main content
Question

Migration of historical data

  • September 24, 2026
  • 5 replies
  • 51 views

Forum|alt.badge.img

Hi everyone,

We are currently working on a historical data migration into Acumatica and would appreciate some guidance on the best approach.

Our requirement is to migrate several years of historical sales data, including:

  • Sales Orders

  • Shipments

  • AR Invoices

For the historical AR invoices, we would like to use AR Migration Mode, as these invoices are being migrated for historical/reference purposes and must not generate any new GL entries.

However, at the same time, we would like to preserve as much as possible the standard Acumatica document relationship and navigation:

Sales Order → Shipment → AR Invoice

Instead of generating the invoice through the normal Prepare Invoice process from the shipment, our idea would be to:

  1. Import the historical Sales Order.

  2. Import/create the corresponding historical Shipment and maintain its relationship with the Sales Order.

  3. Enable AR Migration Mode.

  4. Import the historical AR Invoice directly.

  5. Populate the standard SO/Shipment references on ARTran and, if required, the corresponding invoice references in SOOrderShipment.

  6. Release the AR Invoice while Migration Mode is still enabled, so that no GL entries are generated.

The expected result would therefore be:

Historical SO → Historical Shipment → Migrated AR Invoice

with the documents remaining linked/navigable in Acumatica, but without recreating the accounting entries for the historical invoice.

Has anyone implemented a similar migration?

More specifically:

  • Can the standard SO/Shipment references on ARTran be populated when creating an AR Invoice in Migration Mode?

  • Can SOOrderShipment be updated through a supported Import Scenario/API process to reference the migrated AR Invoice?

  • Would this be sufficient to preserve the standard navigation between SO, Shipment and AR Invoice?

  • Are there any other tables/relationships that Acumatica normally creates during Prepare Invoice that would need to be populated?

  • Is there a supported alternative approach to achieve this without directly updating Acumatica database tables?

Our main constraints are to preserve the historical SO → Shipment → Invoice relationship while ensuring that the historical invoices do not generate GL entries.

Thanks in advance for any guidance or experience with a similar scenario.

 

 

5 replies

valentynbeznosiuk
Jr Varsity III
Forum|alt.badge.img+5

Hi ​@NAWRES 

When AR Migration Mode is activated, the SO Invoice screen isn't available, even though it shares tables with AR Invoice — you won't be able to access them through the Import Scenario. If you try with migration mode turned off to create SO Invoices and add lines through the Add Order action, then turn migration mode on, you won't be able to open that SO Invoice from the AR Invoice form either. So this also blocks the needed result, and I assume it's not possible.

What we normally do is import closed sales as AR invoices only, with the SO and shipment numbers kept as references (in Notes or custom fields). We import only the open sales orders. Using a field instead of Notes makes it easier to search or build a GI on later. It's also worth keeping in mind that importing historical shipments would post inventory issues and COGS through Update IN, which AR Migration Mode doesn't cover.

It would be interesting to hear how others handle this, and whether anyone has found a way to keep the full SO → Shipment → Invoice link.


Forum|alt.badge.img
  • Author
  • Jr Varsity II
  • September 24, 2026

Hello ​@valentynbeznosiuk 

Thank you for your answer. I totally understand that once you activate the migration mode the access to the SO orders will be blocked but the idea is to migrate first Orders and sHipment and then switch to migration mode , migrate AR invoices and build (somehow) the link between this AR invoice and the order and shipment 


Forum|alt.badge.img
  • Author
  • Jr Varsity II
  • September 26, 2026

Hola Everyone,

I found the Order Number (SO) and Order Type among the fields available for AR Invoices.

However, when I populate these fields during the integration, the values are not reflected on the AR Invoice. It looks as though the system is either not reading the values or not taking them into account during the import.

Has anyone encountered this behavior before, or is there a specific configuration/mapping required for these fields to be populated correctly?

Thank you in advance for your help.


valentynbeznosiuk
Jr Varsity III
Forum|alt.badge.img+5

​@NAWRES 

Those fields on both the SO and the AR Invoice can't be edited manually or through an Import Scenario or API. The only way to populate them is through specific actions, such as Create Shipment or Add SO/SO Line on the SO Invoice.

You could try making them editable through Import Scenario with a customization, but it may cause issues, since the system is supposed to populate those values into multiple other tables to keep consistency. With this customization, you'd need to populate the values in all the required places and then thoroughly test the whole system. So it's theoretically possible this way, but the risks are high.


Forum|alt.badge.img
  • Author
  • Jr Varsity II
  • September 26, 2026

Hello ​@valentynbeznosiuk 

 

Thank you for your reply.

I know I probably sound like I’m refusing to give up on this 😊, but I’m really trying to explore every possible workaround that would allow me to migrate five years of sales history while preserving, as much as possible, the relationship between the Sales Orders, Shipments, and AR Invoices.

Based on your feedback, I believe my best option at this stage would be to import the historical Sales Orders and Shipments first, and then import the AR Invoices in Migration Mode.

For the invoices, since I cannot recreate the actual link to the original SO/Shipment, I could create dedicated custom fields to store the original Order Type/Number and Shipment Number for historical reference, as you suggested.

It would not recreate the native relationship between the documents, but at least it would allow us to retain the complete historical references and traceability without generating the accounting impact associated with those historical transactions.

Unless there is another workaround I’m missing, this seems to be the safest approach.