Data Scrubber Utility

Epicor ERP 10
1

Upgrading from 8.03.409C to 10.1. I understand that there is a data scrub utility when upgrading from version 8 to 9. And then there is a different scrub utility when upgrading from 9 to 10. Do we need to run the Data Scrubber utility for 8 to 9 first and then run the 9 to 10 data scrubber utility before migrating our database to 10.1?

Thanks for any help.

2

The approach that I would recommend as someone who supports customers with upgrade/migration issues:

  1. run the 8.03.40x scrubber against a backup of your live database. Any failures, request the fixers from Support at 8.03.40x.

  2. Upgrade from 8.03.4xx to 8.03.410.

  3. Upgrade to 9.05.702a via the DUU.

  4. Request and run the 9.05.702a scrubber against the upgraded 9.05.702a database. Any failures, request the fixers from Support at 9.05.702a.
    NOTE: if there are failures, you’ll have to run the fixers during your go-live pass so plan for that. If there weren’t any failures, then running the “checker” part of the scrubbers is all that needs to be completed during your go-live pass as a just in case measure.

  5. Migrate to 10.1.500.x.

  6. Run the E10.1.500.x native version of what used to be called the 10080 conversion to bring over historical financial data (if you were 8.03.4xx SQL - if you are Progress, then you need to run the 10080 at the 9.05.702a level before step 5 which can take between 5 minutes and 3 days +/- 3 minutes (so please go through a few trial runs to get the timings down). ** Read below for a bit more commentary on this.

  7. Request and run the Health Checker (aka: what we are calling the Scrubbers - we’re rebranding the utility a bit) at 10.1.500.x .

  8. Repeat step 7 on a regular scheduled basis after go-live at 10.1.500.x or whenever requested by Support.

** When using the DUU process, 10080 is technically available to execute when the database is at the 9.04.508 level after mandatory database conversions and it runs much, much faster than when run at 9.05.702a as the source data is in the same database as the destination in E904 but not in E905. Please do not be tempted to run 10080 at 9.04.508 because the 10080 at 9.04.508 is not the same as 9.05.702a and there are changes to this conversion at 9.05.702a that are needed for a successful upgrade/migration.

TL;DR: 10080 at 9.04.508 if Progress/SQL = :cry: , 10080 at 9.05.702a if Progress/SQL = :slight_smile:, “10080” natively in 10.1.500.x instead of running it at 9.05.702a if SQL at 8.03/9.04 = :grinning:

Hope that helps

5 Likes
4

Pinned for posterity! Thank you Nathan

5

Thanks for the help and the reply. Just to confirm the data scrubbing utility comes from epicor support correct? We run it, and then send Epicor our logs from the scrubber, they then recommend a course of action based on the logs correct?

6

Correct

7

So what if you database is Non Unicode SQL 9.05.701 and you want to go to 10.1.500?

702a Unicode
10.1.500?

I have also noticed the OS/SQL requirements are quite specific. Our current server is 2008 R2 SP1 with SQL 2008 R2 SP3. Ideally I’d like to be matching the Windows 2012 R2 and SQL 2016 Stack setup. Is this best achieved by performing the migration on the existing environment then create a new server with Windows 2012 R2 and SQL 2016, Install E10 then do a backup and restore from the old server to the new?

Comments appreciated.

Cheers
Simon Hall

8

Assuming that your new server has newer/faster resources than your existing E905 server, I would suggest the following:

  1. Upgrade from 9.05.701 SQL non-unicode to 9.05.702a on your existing E905 server / on some other server that isn’t your planned E10.1.500 server.
  2. Install E10.1.500.x on new server.
  3. Restore backup of 9.05.702a SQL non-unicode db on new server.
  4. Migrate from 9.05.702a SQL non-unicode to E10.1.500.x on new server.
    NOTE: the migration process itself will create a SQL unicode database, so the E905 database can be either SQL unicode or SQL non-unicode/ISO.

But, you can migrate completely on your existing E905 server and then move the resultant backup to the new E10.1 server as well - my recommendation to complete part of it on the new E10.1 server was just based on the assumption that your newer server is faster.

9

Thanks, That has clarified things. I thought I would have to go from 701 non uni-code to 702a uni-code first. It appears that will not be the case.

Cheers
Simon Hall

10

Wow Nathan, that post was amazing! If I was doing a migration from 8 to 10 I would definitely call you and yell, “Pay the Man! He needs to be a part of our team.” LMAO!

Great post man.

Jonathan Lang

1 Like
11

Took us only 6~ hrs to run 10080 from recollection when upgrading from 8->10.0.700. Database was 70~gb and the server was a VM running a Dell PowerEdge r630 all tripped out with SSD. What did take a mammoth amount of time were the mandatory 9.04 conversions (20 - 24hrs). To put that into perspective it took us almost 60hrs of non stop computer processing to do the entire update.

It helps if you set up some point VMs to do the database upgrade and do the testing. IE one VM with 8.0.400.10, one with the DUU on and then a physical for your final server. You can reset Epicor 8/9 to tell it is hasn’t done the update by changing one of the confit files.

12

Nathan,

We need to convert our database from ISO to UTF, should we do this before or after upgrading to .410? I also assume this has no impact on the data scrub utility?

Thank you for the help.

13

If you’re 8.03 Progress it doesn’t matter when you convert codepages (the datafix works with both codepages) and if you’re SQL 8.03 then I’d do it before the codepage change.