My only concern, is that we'd like to guarantee that, when we import the repository into the new location, that none of the tasks are automatically resumed.
I'd also prefer not to stop the tasks prior to running the first command.
If the service account in the new environment does not have access to the target databases, will that suffice as a method? Will that guarantee that any writing tasks won't start?
The Export/Import Repository feature can be used to migrate a Qlik Replicate environment from one server to another. However, after the migration, a task cannot be resumed from its previous position because the stream position is not transferred as part of the repository export/import process.
Could you please let us know which platform your Replicate server is running on—Linux or Windows?
Depending on your requirements, the following options may be applicable:
Reload the task after the migration. This is the simplest and most straightforward approach.
Restart the task from a specific timestamp, LSN, or SCN. Please note that this may result in duplicate rows unless the target table has a Primary Key or Unique Index and the PK/UI can forcedly prevent the duplicate rows.
Resume the task from its previous broken stream position. If this is a strict requirement, you may want to engage the Professional Services (PS) team to determine whether there is a supported approach for your specific scenario.
Thanks,
John
Help users find answers! Do not forget to mark a solution that worked for you! If already marked, give it a thumbs up!
You should contact Qlik Support or check the product documentation to confirm how your specific Replicate version handles task states during importrepository. It's not something I'd leave to chance in a production migration.
A good practice is to keep the Replicate service stopped on the new server during the import, verify the configuration, then start tasks manually when you're ready. That gives you much more control than relying on database permission failures.
