"Call a CAB" - Migrating Customization Solutions

Epicor ERP 10
,
1

I’m currently working through the process of upgrading to v10.2.600.13 on a test server and I’m stuck on the manner in which I would need to import/migrate all of our customization solutions that we’ve normally packaged as separate CAB files in the Solution Workbench module.

One of the ways I had previously read about doing this process “easily” in bulk is to repackage all of the customizations into one single CAB file, then use the Solution Workbench to import everything in one import action from that single CAB.

Is there really no other way to import customizations, say, during the server deployment phase in the same manner that you can with the “reports.zip” source for all of your custom RDLs?

Has anyone figured out any crafty ways beyond the one-by-one importing method using Solution Workbench?

2

I have done this weekend from E9 to E10. Below was the sequence I followed.

  1. Create required UD fields
  2. Import Functions (one by one). Must import parent one if it’s called by other functions.
  3. Import BPMs
  4. Import Customizations
  5. Import Reports, RDD, Style
  6. Import Dashboards
  7. Import BAQs
  8. Import top-level menus and then other menus (created two cab file)
  9. Import Quick Search
3

You can put them all in a solution cab file for portability.

Customizations will stay with the database during the upgrade process so why will you need to migrate them?

If you are editing them the cab approach works well.

Ross

4

Didn’t know that, Ross. But now that I do, can I assume that the database I just upgraded (handled by Epicor’s schema upgrade process) has all of the old customizations available to me in the new v10.2.600.13 version?

5

It will. If they are heavy coded in the script editor, there might be some things you will have to tweak but generally they will upgrade well within the same major version.

I am assuming you are going from your posted version of 10.2.200.16 to 10.2.600.x

Ross

1 Like
6

Here is what I got from an epicor employee last week- note that we are going live with a vanilla version of our database and brining over what customizations are necessary from a fully converted database:

"Yes, there is one suggested approach for installation steps, which should cover Epicor dependencies within each element:

    1. UD Fields
    1. Regenerate database model in the Epicor Admin Console
    1. UI – customizations (base, customizations and/or localization)
    1. BPMs
    1. BAQs
    1. BAQRpts
    1. BAQRptStyles
    1. Reports
    1. Dashboards
    1. MENU (menus are always last)"
7

@rosshughes – That’s correct.

Performed the upgrade in a test environment last night and, yes, all of our customizations appear to be present (currently in the process of testing them all this morning).

I’m still confused on how all of that is maintained within the database where it simply upgrades automagically. So, a BAQ is not a separate “object” in the application. It’s merely a record within some obscure table in the database? A dashboard (*.dbd) is not an “object” in the application. It’s also a record in the database? Same thing with form/module customizations and their form controls and on-event code? They’re just database records?

8

They’re both. The source is always in the database but that source gets compiled into DLLs.

1 Like
9

…what @Mark_Wonsil said.

For example, see table Ice.QueryHdr or Ice.QueryXX for BAQ data…or Ice.DashBdXXX for dashboard stored information.

Ross

1 Like
10

Thanks, @rosshughes (and @Mark_Wonsil) for the details. I understand now why you don’t have to re-import your customizations (since they’re already integrated in the database). Thanks for the help.

11

There are a few exceptions: SSRS Reports, Document Storage (the files themselves), ServiceConnect workflows, are things that are NOT stored in the database. I’m sure there are others I didn’t mention.