Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster

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

Hello Qlik Community,

We just made a migration attempt of the QVPR from our PROD device to a backup device, and somehow the settings on the backup intertwined with the PROD device, that produced some interesting behaviors (by "interesting" I don't mean "good").

In a prior attempt at migrating the QVPR from the same originating device to a different receiving device, replacing the names of the old devices with the new devices in an edited QVPR, and bouncing the services on the receiving device was enough for a clean migration (no issues reported).

**We did not replace entries any of the ServiceID's such as DistributionServiceID or QlikViewServerID, only references to machine names were changed.**

In this latest instance following the same procedure, the result was a strange intertwining that caused changes entered into the backup QMC to propagate & overwrite settings on the PROD QMC.

What was observed:

The QVPR was imported on the backup device and some of the mount paths were still pointing to the old device (despite that those paths had been updated with the new device name in SourceDocumentFolderResource.xml. It was as if the updated machine names were ignored. In either attempt we did not make any updates to entries for the ServiceID's such as DistributionServiceID or QlikViewServerID)

Then when attempting to "correct" the paths on the backup device manually via the backup QMC, these changes were then observed reaching back to our PROD device. (i.e. our listing of PROD mounted paths began reflecting changes entered via the backup QMC, so now we had two independent QMC connected to our prod environment)

Observing the backup device closer it appears a few things were intertwined:

the qvp://{was still pointing to the old device}

there were two services that had the following configuration:

Service Name: Running On:

QVS@{New device} {Old device}
QVWS@{New device} {Old device}

Not finding documentation that goes into more depth about any additional steps for QVPR import. Should changing the entries of the machine names be sufficient?

Re: Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster

patricio — Tue, 26 Jun 2018 11:00:45 GMT

Hi Evan,

I am in the process of migrating one QVPR from a PROD server to a TEST server.

I found your question very interesting and I would like to know if you reached any conclusion about the need or not to rename any IDs in addition to the server names.

Thanks,

Re: Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster

evan_kurowski — Wed, 19 Sep 2018 21:58:41 GMT

Hello Patricio,

Unfortunately this QVPR migrstion was done as a situational need, and we didn't perform further testing.

But it was definitely alarming to see changes propagating to our Prod instance and questioning "Who's doing these changes! Someone unauthorized is modifying the server!"

It took a few observances before correlating changes made to another environment were "leaking" into prod.

topic Re: Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster in QlikView

Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster

Re: Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster

Re: Attempt at QVPR migration intertwines the QMC between NEW & OLD cluster