Implementing day one fixes during an update

What methods have people used to implement the fixes they’ve found during the testing phase of an upgrade?

I ask this as most of the changes will “reside” in the DB that you’re just going to overwrite right before the upgrade.

I’m assuming the following upgrade plan (open to suggestions on this too!):

  1. Install new version on test server
  2. Copy PROD101400 DB to test server as TEST
  3. Update TEST for new version
  4. User testing on TEST
  5. Fix user findings in TEST. Goto 4 until no more issues
  6. Copy PROD101400 TO PROD102300
  7. Update PROD102300
  8. Apply fixes found in iterations of steps 4 and 5
  9. Go live!

My question is if during testing, you find that customizations, or bpms need to be tweaked, do you just manually do those tweaks that you did in step 5?

Or do you “export” them from the TEST DB, for importing into PROD102300?

And a side question… do you remove all the unused customizations and BPMs that were carried over from the previous version?

I use Solution Workbench to create a solution in the TEST with all the BAQs, Dashboards, BPMs, and customization that need to be tweaked in your step 5. I keep track of those fixes in a spreadsheet, and manually build a Solution with all those fixes in TEST just before I’m ready to go live, but Solution Workbench could also keep track of everything you touch after update in TEST. Then after update in Production db, apply the Solution from TEST and you’re done.

I use solution workbench as well and to answer that question anything I am importing with solution workbench, if possible, I delete from the target DB first. Overwriting has proven to be sketch for me in BPM and UBAQ situations. BPM forms have wanted to go sideways on me a lot too.

1 Like

If I had a dashboard that needed updating, do you suggest just updating that dashboard (keeping the same ID), and then when installing the Solution in PRD102300, have it “write over” the dashboard with the same ID?

Or have make a new dashboard (by copying the one that needs tweaking), and then installing that one (thus preserving the original - albeit not working - dashboard), and including any menus that point to the original dashboard?

Dashboards seem to ride a long plenty fine.

Hi Calvin,

We normally fix it in test, ship it out to central location with all of the other items that need fresh importing after live production database is upgraded, and add it to a list of what needs to be done after prod upgrade. Sometimes I need extra notes on the order of doing things. For example, don’t assign something to the main menu until it’s been imported.

We usually keep the last rev or two of customizations in production. We do not do this with our bpms, reports, or dashboards however.


1 Like

The more I think about it, customizations and Reports (SSRS’s RDL and CR’s RPT) are the only things that we create a new ones.

BAQ’s, BAQ Reports, BPM’s, and Dashboards, usually just get updated. Mostly because they can be referenced from many other areas, and updating all those references would be a chore.

While updating all the menus that reference a customization is a pain, by having a new and the prior one on the system, I can actually make a menu item for each - usually disabling the old one. Then if problems arise, I can just re-enable the old one, and disable the new one.

Yes, we have found the same. One thing we have found useful however, is to place a Rev notation on top tab of customization and save the customization as this, e.g., SalesOrderEntryRev6. However at deployment, we import this rev 6 into Production and then deploy it as a generic name, SalesOrderEntryTUSA. The current TUSA one gets deleted right before save of customization with same name. When deleted via customization maintenance, it doesn’t wipe out user’s personalizations. So the Rev 6 one gets saved as SalesOrderEntryTUSA, keeps all personalizations, and shows it’s Rev6 on the top tab.

This makes deployment a breeze in that the customization is already assigned in the menu.


1 Like

We do the same thing with setting the Form title to include the customization “revision”. We then set the menu display to include that as well


That idea about having a customization that you just overwrite, but keep the same name is pretty good. But we’d still need to go through and update the menus - if we wanted to keep doing what I pointed out above.

1 Like