topic Re: Inquiry Regarding Setting Up a Test Server After Cloning the Production Server in QlikView

Inquiry Regarding Setting Up a Test Server After Cloning the Production Server

qwebnm — Mon, 26 Jan 2026 18:19:17 GMT

To the Qlik Team,

Hello,

We are planning to clone the QlikView and NPrinting servers currently in operation on VMWare in order to establish a test server.

We would like some advice on precautions to take during this process.

Our intention is to configure the test server in a way that does not impact the production server when cloning.

We plan to make changes such as altering the IP address and stopping the QlikView and NPrinting services on the duplicated test server.

Upon restarting the Test Server Qlik services, we aim to apply the test license provided by Qlik for testing purposes.

Are there any considerations we should be aware of when starting the Qlik services on the test server?

Will there be any impact on DNS, IIS configurations, or the DB server connected to the actual production server?

We would like to know if there are any precautions or changes that need to be made.

If possible, we kindly request guidance on this matter.

Thank you.

Re: Inquiry Regarding Setting Up a Test Server After Cloning the Production Server

Miguel_Angel_Baeyens — Thu, 30 Nov 2023 11:43:12 GMT

Generally speaking and based on experience: do not clone VMs, rather than install QlikView on the new computers, and the copy configurations from the production servers to the new servers, following the steps here: https://community.qlik.com/t5/Official-Support-Articles/QlikView-Migrating-to-a-different-machine/ta-p/1712646 and the detailed steps here: https://help.qlik.com/en-US/qlikview/May2023/Subsystems/Server/Content/QV_Server/QlikView-Server/QVSRM_UpgradeMigrationQV_diff.htm.

DNS, hostnames, IP addresses all have an impact in configurations and are better addressed when the product is installed anew.

Re: Inquiry Regarding Setting Up a Test Server After Cloning the Production Server

marcus_sommer — Fri, 01 Dec 2023 09:57:20 GMT

You may also need a dump from your DB to avoid any overload or conflict there respectively to the network resources. An alternatively might be to implement a rawdata-extractor layer which just pulled the rawdata without any transformation from the DB and stored them as qvd's. If both environments access the identically qvd-layer there would be further conflicting-risks but probably lesser as by accessing the same DB. But even this could be minimized by doubling the file-storage and synchronizing it with tools like robocopy.