Kevin

Much of what you need to bring across is going to be files associated with the either customizations and integrations or library files that form part of the business data.

Consider:

CustomDotNet - these are the files that extend Sage CRM using the .NET API. This may contain files used by customizations, components or integrations.

DataUpload - XLS and CSV files containing data previously uploaded.

inf - Components that have been installed or available to be installed.

Library - Files created by mailmerge or documents uploaded and associated with business data.

License Update - A utility used to update a license

Logs - Historical logs used for diagnosing issues. Controlling by settings in Admin Screens.

Quickfind - Settings for the QuickFind feature.

readme - Self Service demo information

Setup - Files copied onto server by install shield as part of configuration of Sage CRM. Only used in set up.

Setup_bak - A backup of settings files for an upgraded system.

tomcat - Java files, settings and configuration for the Apache Tomcat web server and webapps

WWWRoot - All custompages, custom javascript files, stylesheets and images that used within Sage CRM interface. May contain files used by customizations, components or integrations.

Hi Kevin

I normally do the following steps

1. On the new server install the same version of CRM

2. Stop IIS on the new server

3. Restore over the database with a backup of your live CRM

4. Copy over the WWWRoot and Library folders from within the CRM folder to the new server into the same location

Within the database run the query (assume my new server is called 'server1')

UPDATE Custom_Sysparams

SET parm_value = 'server1;' --Note the semi colon!!

WHERE parm_name = 'ServerNames'

If the original CRM is NOT installed into the default location (C:\Program Files (x86)\Sage\CRM\CRM\) then you will need to do some updates in Custom_Sysparams to point it to the location you have installed one the new server.

e.g. check out Parm_name values.

DocTemplates

ReportsRootDir

DocStore

DotNetDirectory

JavaPath

Starting up the CRM QuickFind service will rebuild it's index, as will CRM Index Service will sort out the FullText folder within the Library folder.

Finally restart IIS.

Jeff & Bultark, thanks for the reply. Libray folder is not a problem, that is not currently in the default install directory. I'm afraid to just do a copy over everything from existing server to new one, because I'm sure there are alot of files on existing server that aren't needed on new server. Below is pic showing folder structures between the 2 servers. I know in the THEMES folder on the existing server there are almost 10K files in it and on the new server only like 2K. Doesn't Sage have a list of files that are static and never change on an install and the ones that could change and need to be copied over?

CRM is basically the WWWRoot folder, hence why I have never looked to 'partially' move it. I have always copied the entire folder regardless. you're right there are things in there that are common to installations (e.g. Plugins). But even something you think would be static might not be, in the example of Themes we often put in there files which make up custom icons / buttons / images for selections. so wouldn't want to loose those.

There are things that are no longer needed over time through doing upgrades (e.g. Training - the help is all online now unless you download it) But as it is only generally about 1.5Gb in size I tend not to worry

The two folders in your SageCRM folder (Snapshots & SqlLite) I have never seen - but then I have never installed CRM into it's SQLExpress so guessing these might be to do with that.

Kevin

From the screenshots that you've provided I can see that your original install of Sage CRM has been upgraded from several versions previously. I can see this because the SQLLite and Snapshot folders belong to a feature for Sage CRM called SOLO that was dropped long ago.

Note: A fresh install of Sage CRM 7.3sp3 would use identity columns to generate the primary key values for records. BUT a system that has been updated from a version that worked with SOLO will use a stored procedures to generate the unique values. You may want to double check with the support team their recommended path.

Likewise the addon that is used to provide the WYSIWYG editor for emails has changed its name from Fckeditor to ckeditor.

These changes have all been documented in release notes and in the technical deep dives that are added to the community for each main release. There isn't a single document to describe the changes and partly this is down to the very large number of variants of upgrade paths and possibilities that exist.

But from looking at the files my hunch is the biggest question you have to resolve is around the generation of primary keys. A new instance of Sage CRM 7.3sp3 is going to want to use 'Identity' columns but one upgraded from an earlier version will expect to use the StoredProc mechanism.

You could be fine, when doing upgrades I only move the WWWRoot folder.

E.g. Going from v7.1 (which used the Stored Procedure method of handling SQL IDs) I would have to move it into a VM to partial upgrade. I think there is something in the database that records which method it uses to handle the IDs

Here is recent upgrade I did which worked without issue and all is running fine as we speak.

v7.1 on Windows 2008, but the new server was Windows 2016 (which v7.1 fails to install on), But I have a VM with 2012 in it.

I install v7.1 a fresh in my VM and stop IIS then copy over the database and the WWWRoot folder and restore the database and overwrite the WWWRoot folder. Then I upgrade through the steps as normal to v7.3 SP2 (the first version is that is supported on Windows 2016).

Then on the new server I install v7.3 SP2 a fresh and stop IIS and copy over my newly upgraded database and WWWRoot folder and again restore / overwrite as before. Now on the new server I can upgrade to v7.3 SP3 or jump to CRM 2017

Thanks for the suggestions, since we have some time to test this move, we will explore our options, but I'm guessing we will have to move the whole program file over since we have been using the software for so long to prevent any possible issues.