Sage 100

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

------------------------------
Wayne Schulz
wayne@s-consult.com
Schulz Consulting
(860) 516-8990
Moodus, CT
------------------------------

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

thanks Kevin, 

i did run the Migration, it just failed with the Alter error.  the mas_system database did restore.   I was interpreting Wayne's post as saying that he was able to manually restore the company databases after this point?       or was he saying he did that after fulling completing the migration once?     

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

thanks Kevin, 

i did run the Migration, it just failed with the Alter error.  the mas_system database did restore.   I was interpreting Wayne's post as saying that he was able to manually restore the company databases after this point?       or was he saying he did that after fulling completing the migration once?     

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

Here's what I did: 

Once you get your new/upgraded copy of Sage 100 staged but before you migrate anything - backup the \MAS90 and any SQL databases on the new server(s). Repeat this process anytime you are going to refresh the data. If the customer is using Azure or some hosting that makes it difficult to expand and contract storage on the main drive I have had good luck asking them to create a temporary additional drive just to hold the backups during this upgrade process.

1. As Kevin notes, you need at least one clean migration of MAS_SYSTEM - I usually also have MAS_XXX migrated and converted at this point
2. For subsequent conversion to refresh the data - if it's an existing Premium I backup only the MAS_XXX from the prior Premium install and restore to the Sage 100 ( noted in step 1 above ). But this is only after I have one clean migration.
3. I make a full backup of \MAS90 and any SQL databases before attempting to do any second or subsequent updating of data
4. Then reconvert the data

thanks Kevin, 

i did run the Migration, it just failed with the Alter error.  the mas_system database did restore.   I was interpreting Wayne's post as saying that he was able to manually restore the company databases after this point?       or was he saying he did that after fulling completing the migration once?     

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

Not redoing the system migration has risks... you'll miss UDF / UDT changes, new users, changed passwords, Paperless records... anything done at the system level in the source system has to be redone in the new system (or copied manually) if you skip the system re-migration. 

It's up to you to determine what's a bigger headache: redo the system migration or skip it and deal with all those extra details manually.

Here's what I did: 

Once you get your new/upgraded copy of Sage 100 staged but before you migrate anything - backup the \MAS90 and any SQL databases on the new server(s). Repeat this process anytime you are going to refresh the data. If the customer is using Azure or some hosting that makes it difficult to expand and contract storage on the main drive I have had good luck asking them to create a temporary additional drive just to hold the backups during this upgrade process.

1. As Kevin notes, you need at least one clean migration of MAS_SYSTEM - I usually also have MAS_XXX migrated and converted at this point
2. For subsequent conversion to refresh the data - if it's an existing Premium I backup only the MAS_XXX from the prior Premium install and restore to the Sage 100 ( noted in step 1 above ). But this is only after I have one clean migration.
3. I make a full backup of \MAS90 and any SQL databases before attempting to do any second or subsequent updating of data
4. Then reconvert the data

thanks Kevin, 

i did run the Migration, it just failed with the Alter error.  the mas_system database did restore.   I was interpreting Wayne's post as saying that he was able to manually restore the company databases after this point?       or was he saying he did that after fulling completing the migration once?     

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

Shannon - 

I just went through one of these as well.  My observation is that there is a slew of errors, most of which are related to (a) using the migrate option and (b) migration of MAS_SYSTEM.

In short, here's what I had to do: 

1. Make backups of MAS_SYSTEM and MAS_XXX and \MAS90 very regularly (this is ABSOLUTELY MANDATORY as there are a whole slew of issues which appear to render MAS_SYSTEM unreadable, and if you don't have a copy to restore the Sage KB only advises "too bad/so sad - have fun reinstalling". I kid you not.
2. I had to do one migration that included MAS_SYSTEM
3. Once I did the initial migration, I tested and went live by backing up MAS_XXX from the initial install of premium ( in my case, v2018). Then I went to the v2022 Premium, and I dropped ( deleted ) the MAS_XXX  -- KEEP MAS_SYSTEM - and restored the v2018 MAS_XXX to SQL. Then I converted the data through regular Sage company maintenance.
4. This leaves a few issues - if they have added users, UDFS, screen customizations, or changed security, you'll need to add those to v2022 manually. You'll also need to deal with the paperless office files that are in MAS_SYSTEM - in my case, I (or rather Jim Woodhead ) used a query to move the table data from 2018 to 2022 for the PLJournalPDFLog. I then could move the source paperless PDF files and change their location (paths) using the regular tools we have for paperless migration to new location.

Carmen did a GREAT session on this and has a set of handouts which document the steps.

The biggest advice I can give is to protect MAS_SYSTEM by backing up frequently. I had several instances where my MAS_SYSTEM got hosed -- including once during go-live -- and restoring the MAS_SYSTEM absolutely saved the installation. This is especially critical if the customer has multiple integrations since you probably have been having at least some third-parties doing advance work to prepare their portion before the upgrade.

thanks Kevin, 

i did run the Migration, it just failed with the Alter error.  the mas_system database did restore.   I was interpreting Wayne's post as saying that he was able to manually restore the company databases after this point?       or was he saying he did that after fulling completing the migration once?     

You need the Sage migration to do the MAS_System copy fully and completely because there is more involved than just the database copy from the source system.  (Basically, it updates the old database with changes required to run the new version...).  Premium to Premium migrations cannot be done manually.

Make sure the SQL services are running using domain accounts with local admin permissions to the server(s).  Stop everything that might be using SQL (services, external queries, scheduled tasks...).  Restarting the SQL services just before starting the migration is one way to break connections you can't find.

This might also help:

Hello

If i get this error but see that the mas_system database has been restored to the new sql server, are you saying i can manually restore the company databases and then try to convert?    I asked Sage for a patch this week for this (2018 to 2022 pu2), it was labeled 2023 migrate.zip but he said it was for 2022 but it errored as soon as i chose the source sql database.   The KB is not listed anymore for this.     TIA  Christine

I've been doing this for Premium upgrades... as a part of our internal checklist.

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

I've been doing this for Premium upgrades... as a part of our internal checklist.

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

I've been doing this for Premium upgrades... as a part of our internal checklist.

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles
------------------------------


Original Message:
Sent: 03-17-2023 11:43
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.


Original Message:
Sent: 03-17-2023 11:35
From: Doug Higgs
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles


Original Message:
Sent: 03-17-2023 11:15
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

I've been doing this for Premium upgrades... as a part of our internal checklist.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.

No, the regular migration programming only requires that the new SQL instance is no lower than the source SQL instance.  It (new instance) can be the same, or higher.  (This is actually a SQL requirement due to how backup and restore works in SQL, not a Sage requirement). 

Where did you get the idea they had to be the same?

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
------------------------------


Original Message:
Sent: 03-17-2023 11:45
From: Doug Higgs
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles


Original Message:
Sent: 03-17-2023 11:43
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.


Original Message:
Sent: 03-17-2023 11:35
From: Doug Higgs
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles


Original Message:
Sent: 03-17-2023 11:15
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

I've been doing this for Premium upgrades... as a part of our internal checklist.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.

@Kevin Moyes   I believe you are correct on the higher version, although I have had issues in the past.  See the attached KB. I believe the issue I typically have seen that causes a failure is the patch level.  IT says "SQL 2019 is installed on both servers".  If SQL 2019 doesn't have the exact same patch level then the migration fails.

No, the regular migration programming only requires that the new SQL instance is no lower than the source SQL instance.  It (new instance) can be the same, or higher.  (This is actually a SQL requirement due to how backup and restore works in SQL, not a Sage requirement). 

Where did you get the idea they had to be the same?

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.


Original Message:
Sent: 03-17-2023 11:45
From: Doug Higgs
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles


Original Message:
Sent: 03-17-2023 11:43
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.


Original Message:
Sent: 03-17-2023 11:35
From: Doug Higgs
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

------------------------------
Doug Higgs
Midwest Commerce Solutions, Inc
(312) 315-0960
Chauffeur, Chef, and Personal Assistant to Sprinkles


Original Message:
Sent: 03-17-2023 11:15
From: Kevin Moyes
Subject: SQL error - Unhandled exception ALTER DATABASE FAILED

I've been doing this for Premium upgrades... as a part of our internal checklist.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

I've been doing this for Premium upgrades... as a part of our internal checklist.

First, my experience is the Sage migration tool is problematic. I don't know if versions caused the issue. 

I got at least two error-free test migrations (system and data ) going from SQL 2016 to SQL 2019.

After receiving and reading about various error messages - I abandoned the migration tool for my final go-live migration ( so far as I know, you need to use migrate at least once to get all the system files over and updated )

I'm uncertain Sage will resolve what I see as a problematic migration of Premium to Premium so for now I just keep good notes and watch the 90 Minds messages for workarounds and experience.

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

I've been doing this for Premium upgrades... as a part of our internal checklist.

I still use the Sage migration tool, but always take good backups at every stage.

If re-migrating system files gives me an error, I do the extra checking (looking for UDF / UDT changes, new users...) and just re-migrate company data.  (If you don't use the Sage migration tool, you'll be missing the updated Paperless records...).

Yes, the migration tool is extraordinarily sensitive to a number of issues, but if you can change the SQL Service accounts to a domain account that is a local admin to all servers involved (source SQL, new SQL, new Sage...), and run the backup I mentioned above (to verify folder permissions?) it usually works.

The real problems happen when you don't have control over the SQL Service accounts.  That makes some things almost impossible.  (Windows Credentials Manager can help, but not always).

First, my experience is the Sage migration tool is problematic. I don't know if versions caused the issue. 

I got at least two error-free test migrations (system and data ) going from SQL 2016 to SQL 2019.

After receiving and reading about various error messages - I abandoned the migration tool for my final go-live migration ( so far as I know, you need to use migrate at least once to get all the system files over and updated )

I'm uncertain Sage will resolve what I see as a problematic migration of Premium to Premium so for now I just keep good notes and watch the 90 Minds messages for workarounds and experience.

@Kevin Moyes   That's using a manual backup and restore, correct?  Using the Sage migration tool I believe, you have to have the exact version and patches.

Doug,

You can restore a database to a higher version of SQL, so it is perfectly fine if the new SQL instance is a newer version.

If you want to use the original SQL instance for the Live upgrade system, (eg. because of existing setups that are too hard to redo), then the instances do have to be exactly the same (down to the patch level) because you have to do the upgrade migration, then copy the databases back, and that only works if the instances match exactly.

Not sure if this was mentioned previously: Always check the SQL version on the source instance and the destination instance and make sure the versions are exactly the same.  This is a Sage requirement that doesn't make sense.  Since certain versions of SQL are only compatible with certain versions of Sage 100 then how does one migrate from Sage 100 version 2016 / SQL 2014 (most recent compatible version) to Sage 100 version 2022 SQL 2019 (least recent compatible version)?  The only way to do it is to first migrate using the SQL 2014 then upgrade to SQL 2019 later.  We're having fun now!

I've been doing this for Premium upgrades... as a part of our internal checklist.