There are several reasons when it could be sensible to consider cloning a Sage X3 server. For example, if you have a LIVE server which you are planning to upgrade and wish to take a clone of the LIVE server so you can run a test upgrade.   Cloning allows you to perform a test on an exact copy of LIVE (or at least similar), so you can have full confidence your LIVE upgrade will go smoothly (assuming the testing went smoothly of course!)    Another situation may be that you want to create a general TEST system after having just gone LIVE with a new system, as cloning would give you a replica of LIVE on which to perform any testing going forward.

So how easy is it to clone a X3 LIVE instance to a TEST instance?

NOTE: I would not recommend using Cloning to create a LIVE server. This article deliberately concentrates on creating a cloned TEST server.

There are several choices as to the approaches you can consider taking to achieve this requirement:

Method 1: Create new TEST server and copy LIVE data across

This method is taught by the Sage Centre of Excellence (COEX) team. The general approach is to:

• Create/configure new server(s) as required for your target architecture
• Perform a new installation of Sage X3 components as required
• Copy over required MongoDB/SQL Server data from source to target, then bring into target instance

Advantages:

• Methodology can be used for physical hardware as well as virtualised servers
• Initial setup steps follow existing fresh installation steps, so well proven and documented
• Easy to setup different target architecture if needed (although this would obviously introduce differences between your LIVE and CLONE instances)

Disadvantages:

• This method is not a “clone” by any stretch of the imagination, so will be differences in Windows Server and/or SQL Server versions and configuration, and more generally pretty much anything could be different between LIVE and CLONE servers apart from the data itself!
• Same time and effort needed as a new installation (well, it is a new installation after all!) followed by additional steps needed to copy the data over
• The full steps of this method are only covered in a paid-for training class from COEX, who would then provide any support to cover issues or questions with this methodology

Method 2: (For a virtualised environment) Clone into a separate isolated VLAN

This method is the “purest” clone, as it provides the closest possible option for an identical setup for CLONE and LIVE instances. It does pose some challenges and depends on your virtual provider/software as to how feasible and easy this option is to implement.

Basic steps:

• Clone all servers from your LIVE instance to a separate VLAN, which is isolated from your live network
• Sort out the networking side to ensure cloned servers only talk to each other, but users can access them for testing

Advantages:

• Should be easy to clone single or multi-node server instances using VM software
• Retains same hostnames so no reconfiguration needed
• Cloned servers should be identical to the original servers (Maybe different IP address)

Disadvantages:

• Need to be very careful about isolating the cloned VLAN so there is no possible way for the clone servers to be picked up from LIVE network or vice-versa. It would be prudent to ensure your LIVE and CLONE servers are all protected by firewall rules that only allow access to the ports and IP addresses needed to function (this should already have been done anyway for security best practise)
• You need to work out details such as hostname resolution and Windows account validation, particularly if using Active Directory. For example, may need to consider cloning an AD server into the Clone VLAN if using domain accounts for Windows Services
• Target architecture needs to be same as source architecture
• Need to work out how to safely allow user access to the CLONE VLAN for testing purposes
• Sage has no documentation nor specific experience or expertise in this area; any issues encountered would need to be resolved in conjunction with your own resources

Method 3: (For a virtualised environment) Clone and rename

This method allows you to create a near identical setup but does require a hostname change. This means some reconfiguration is needed, although is relatively straightforward as networking changes are not required.

Basic steps:

• Clone all servers from your LIVE instance, then change the hostnames of the CLONE servers. The cloned servers will have their own IP addresses, as normal.
• Update SQL server for the new hostname
• Update Sage X3 classic setup files, MongoDB, Syracuse, etc. for the new hostname and run reconfiguration in the X3 console
• Finishing touches within X3, same as needed for a folder import across instances

Advantages:

• Should be easy to clone single or multi-node server instances using VM software
• Cloned servers can be on the normal live network, i.e. no separate VLAN is needed

Disadvantages:

• You need to prevent any possibility of cross-contamination between your LIVE and CLONE servers, especially whilst the clone is being created and renamed. It would be prudent to ensure your LIVE and CLONE servers are all protected by firewall rules that only allow access to the ports and IP addresses needed to function (this should already have been done anyway for security best practise)
• Target architecture needs to be same as source architecture
• Manual updates and reconfiguration are needed to take account of the new hostname. There is therefore a risk this process could introduce differences between LIVE and CLONE due to these reconfiguration steps
• Sage has no official documentation to share; any issues encountered would need to be resolved with your own resource. I have shared my own experiences of cloning a TEST server by publishing a Build Diary.You will find it in the Build Diary Index

General consideration for all cloning methods

• Understand and take into account any inbound or outbound data feeds/interfaces you may have. For example, SOAP/REST requests, FTP transfers of files for import, etc.
• What will you do about sending emails from the CLONE instance, if required. For example, if you are going to be testing Workflow authorisations do you direct all emails to one test email account, or do you send to the original recipients; but then how do they distinguish between CLONE and LIVE emails?
• Understand what additional software you may be using and how to re-configure/access/test as appropriate
  • For example, SEI, EM&A, V1, Datalinx, etc.
• How to ensure users can easily distinguish if it’s the LIVE or CLONE instance they are working on?

Further reading

Which firewall ports need to be open in a multi-node environment

Conclusion

Cloning servers is not quite as easy as it sounds, but can be achieved with careful planning and appropriate consideration. Whilst Sage Support do not provide direct assistance with cloning, hopefully this article has given you some pointers and ideas of what to consider.