Sage 100

• You are effectively skipping the migration step and doing it by hand
• You can upgrade a system without using a separate SQL server to stage the database upgrade by doing this
  
  • Make sure you have everything backed up
• If you are changing DB servers you can do a back up and restore of the MAS_SYSTEM (and MAS_XX) to the new DB server
• You do need to manually copy the almost empty MAS90\MAS_XXX folders to the new version version
• You would also need to manually copy any custom reports that are located in the MAS90\Reports dir
• I am sure if there are other manual steps that I have not had the pleasure of having to troubleshoot yet

This is a great topic/observation Kevin. 

From a hosting perspective, it's also a whole different process that we have for Premium to Premium migrations.

Unfortunately, because of the dependency on the customer's on-prem environment, we are unable to create a standard specific process for these migrations, so they greatly vary in effort and cost to complete the migration, especially that we'd need to do a test migration and then another one for go-live. 

We've done things like a complete manual move of MAS90 + SQL into a second same version server and readjusting configurations to get it up and running and then do parallel migration within the same LAN where SQL is accessible to the latest version. 

In other instances, we managed to get the SQL port open just for the duration of the migration to get the initial data set. 

Just those 2 are extremely laborious and time consuming. 

When our customers are doing upgrades within our environment, Premium to Premium, we have a few options for them with a few price points as well, that would give them their options for downtime as well, where the best option we offer is to literally make a clone of their server offline and make it available to the new server for their test migration, as to not to interrupt their production.  (That is the more costly option, but also, has 0 downtime for their production during the whole migration process, except for the go-live. 

All this to say, I agree with you 100%. There is no reason why this process can't be improved so that it can be completely done offline. 

When Sage does the Parallel Migration it goes to the source server to path \\servername\e$ (administrator type of share) all the way to the data folder where the .mdf and.ldf sql database files are located.  It wants to create a BAK file.  It will then copy that BAK file to the new location and proceed with getting it into SQL Server.  However from what I am hearing Sage is on one server and SQL is on another. 

So to make this work correctly do the following: 

1. Connect to the SQL server for both the source and destination.
2. Go into Services. 
3. Go to SQL Server (MSSQLSERVER)  if your using the default instance.  If not look for the one that has your SQL instance name in the brackets. 
4. Right click and select Properties
5. Click on Login
6. Change to Administrator sign-on and password
7. Complete this task for both SQL Server instances for Source and Destination
   
   By default Microsoft uses "NT System/MASSQLServer" account and password which is created by them.  It does not have the rights to get to hidden Admin share paths.  That is why it needs to be an Administrator account when SQL and Sage are on seperate servers.  This change allows rights to communicate between the network via the hidden admin shares.  i.e. "\\Servername\E$"

This is a great topic/observation Kevin. 

From a hosting perspective, it's also a whole different process that we have for Premium to Premium migrations.

Unfortunately, because of the dependency on the customer's on-prem environment, we are unable to create a standard specific process for these migrations, so they greatly vary in effort and cost to complete the migration, especially that we'd need to do a test migration and then another one for go-live. 

We've done things like a complete manual move of MAS90 + SQL into a second same version server and readjusting configurations to get it up and running and then do parallel migration within the same LAN where SQL is accessible to the latest version. 

In other instances, we managed to get the SQL port open just for the duration of the migration to get the initial data set. 

Just those 2 are extremely laborious and time consuming. 

When our customers are doing upgrades within our environment, Premium to Premium, we have a few options for them with a few price points as well, that would give them their options for downtime as well, where the best option we offer is to literally make a clone of their server offline and make it available to the new server for their test migration, as to not to interrupt their production.  (That is the more costly option, but also, has 0 downtime for their production during the whole migration process, except for the go-live. 

All this to say, I agree with you 100%. There is no reason why this process can't be improved so that it can be completely done offline. 

When Sage does the Parallel Migration it goes to the source server to path \\servername\e$ (administrator type of share) all the way to the data folder where the .mdf and.ldf sql database files are located.  It wants to create a BAK file.  It will then copy that BAK file to the new location and proceed with getting it into SQL Server.  However from what I am hearing Sage is on one server and SQL is on another. 

So to make this work correctly do the following: 

1. Connect to the SQL server for both the source and destination.
2. Go into Services. 
3. Go to SQL Server (MSSQLSERVER)  if your using the default instance.  If not look for the one that has your SQL instance name in the brackets. 
4. Right click and select Properties
5. Click on Login
6. Change to Administrator sign-on and password
7. Complete this task for both SQL Server instances for Source and Destination
   
   By default Microsoft uses "NT System/MASSQLServer" account and password which is created by them.  It does not have the rights to get to hidden Admin share paths.  That is why it needs to be an Administrator account when SQL and Sage are on seperate servers.  This change allows rights to communicate between the network via the hidden admin shares.  i.e. "\\Servername\E$"

This is a great topic/observation Kevin. 

From a hosting perspective, it's also a whole different process that we have for Premium to Premium migrations.

Unfortunately, because of the dependency on the customer's on-prem environment, we are unable to create a standard specific process for these migrations, so they greatly vary in effort and cost to complete the migration, especially that we'd need to do a test migration and then another one for go-live. 

We've done things like a complete manual move of MAS90 + SQL into a second same version server and readjusting configurations to get it up and running and then do parallel migration within the same LAN where SQL is accessible to the latest version. 

In other instances, we managed to get the SQL port open just for the duration of the migration to get the initial data set. 

Just those 2 are extremely laborious and time consuming. 

When our customers are doing upgrades within our environment, Premium to Premium, we have a few options for them with a few price points as well, that would give them their options for downtime as well, where the best option we offer is to literally make a clone of their server offline and make it available to the new server for their test migration, as to not to interrupt their production.  (That is the more costly option, but also, has 0 downtime for their production during the whole migration process, except for the go-live. 

All this to say, I agree with you 100%. There is no reason why this process can't be improved so that it can be completely done offline. 

When Sage does the Parallel Migration it goes to the source server to path \\servername\e$ (administrator type of share) all the way to the data folder where the .mdf and.ldf sql database files are located.  It wants to create a BAK file.  It will then copy that BAK file to the new location and proceed with getting it into SQL Server.  However from what I am hearing Sage is on one server and SQL is on another. 

So to make this work correctly do the following: 

1. Connect to the SQL server for both the source and destination.
2. Go into Services. 
3. Go to SQL Server (MSSQLSERVER)  if your using the default instance.  If not look for the one that has your SQL instance name in the brackets. 
4. Right click and select Properties
5. Click on Login
6. Change to Administrator sign-on and password
7. Complete this task for both SQL Server instances for Source and Destination
   
   By default Microsoft uses "NT System/MASSQLServer" account and password which is created by them.  It does not have the rights to get to hidden Admin share paths.  That is why it needs to be an Administrator account when SQL and Sage are on seperate servers.  This change allows rights to communicate between the network via the hidden admin shares.  i.e. "\\Servername\E$"

This is a great topic/observation Kevin. 

From a hosting perspective, it's also a whole different process that we have for Premium to Premium migrations.

Unfortunately, because of the dependency on the customer's on-prem environment, we are unable to create a standard specific process for these migrations, so they greatly vary in effort and cost to complete the migration, especially that we'd need to do a test migration and then another one for go-live. 

We've done things like a complete manual move of MAS90 + SQL into a second same version server and readjusting configurations to get it up and running and then do parallel migration within the same LAN where SQL is accessible to the latest version. 

In other instances, we managed to get the SQL port open just for the duration of the migration to get the initial data set. 

Just those 2 are extremely laborious and time consuming. 

When our customers are doing upgrades within our environment, Premium to Premium, we have a few options for them with a few price points as well, that would give them their options for downtime as well, where the best option we offer is to literally make a clone of their server offline and make it available to the new server for their test migration, as to not to interrupt their production.  (That is the more costly option, but also, has 0 downtime for their production during the whole migration process, except for the go-live. 

All this to say, I agree with you 100%. There is no reason why this process can't be improved so that it can be completely done offline. 

This is a great topic/observation Kevin. 

From a hosting perspective, it's also a whole different process that we have for Premium to Premium migrations.

Unfortunately, because of the dependency on the customer's on-prem environment, we are unable to create a standard specific process for these migrations, so they greatly vary in effort and cost to complete the migration, especially that we'd need to do a test migration and then another one for go-live. 

We've done things like a complete manual move of MAS90 + SQL into a second same version server and readjusting configurations to get it up and running and then do parallel migration within the same LAN where SQL is accessible to the latest version. 

In other instances, we managed to get the SQL port open just for the duration of the migration to get the initial data set. 

Just those 2 are extremely laborious and time consuming. 

When our customers are doing upgrades within our environment, Premium to Premium, we have a few options for them with a few price points as well, that would give them their options for downtime as well, where the best option we offer is to literally make a clone of their server offline and make it available to the new server for their test migration, as to not to interrupt their production.  (That is the more costly option, but also, has 0 downtime for their production during the whole migration process, except for the go-live. 

All this to say, I agree with you 100%. There is no reason why this process can't be improved so that it can be completely done offline. 

FYI,
In case anyone wants to vote for change...
https://community.90minds.com/idea/sy-simplify-premium-to-premium-upgrade-process

After 5 or 6 or 7 attempts at trying to migrate from 2015 Premium on one server to 2022 on another server, including reinstalling enhancements, and doing the various steps that we've tried before and some of my memory of what Carmen told us during MOTM, I finally had success with this series of steps:

Copy the v2015 MAS90 folder from the old server to the new server

Backup/restore 2015 MAS_System and MAS_xxx databases from old server to a new temp instance on the new server

Never tried to get into this temp copy

When I run the migration tool, I point the source data to my temp copy of 2015 MAS90 folder and change the default path of SQL from where it is on live 2015 to my temp instance where I put copies of the 2015 databases.

Migration finished/merged successfully.

I was able to get into new version.

Just sharing what worked for me in case it helps anyone else out!

FYI,
In case anyone wants to vote for change...
https://community.90minds.com/idea/sy-simplify-premium-to-premium-upgrade-process

After 5 or 6 or 7 attempts at trying to migrate from 2015 Premium on one server to 2022 on another server, including reinstalling enhancements, and doing the various steps that we've tried before and some of my memory of what Carmen told us during MOTM, I finally had success with this series of steps:

Copy the v2015 MAS90 folder from the old server to the new server

Backup/restore 2015 MAS_System and MAS_xxx databases from old server to a new temp instance on the new server

Never tried to get into this temp copy

When I run the migration tool, I point the source data to my temp copy of 2015 MAS90 folder and change the default path of SQL from where it is on live 2015 to my temp instance where I put copies of the 2015 databases.

Migration finished/merged successfully.

I was able to get into new version.

Just sharing what worked for me in case it helps anyone else out!

After 5 or 6 or 7 attempts at trying to migrate from 2015 Premium on one server to 2022 on another server, including reinstalling enhancements, and doing the various steps that we've tried before and some of my memory of what Carmen told us during MOTM, I finally had success with this series of steps:

Copy the v2015 MAS90 folder from the old server to the new server

Backup/restore 2015 MAS_System and MAS_xxx databases from old server to a new temp instance on the new server

Never tried to get into this temp copy

When I run the migration tool, I point the source data to my temp copy of 2015 MAS90 folder and change the default path of SQL from where it is on live 2015 to my temp instance where I put copies of the 2015 databases.

Migration finished/merged successfully.

I was able to get into new version.

Just sharing what worked for me in case it helps anyone else out!

FYI,
In case anyone wants to vote for change...
https://community.90minds.com/idea/sy-simplify-premium-to-premium-upgrade-process