v15collectionremap.cfg is used to map v15 collection IDs to v16/Squiz DXP search package IDs.

This configuration can only be modified by a system administrator.


A breaking change was made to collection IDs between v15.24 and v16.0 to introduce the concept of a client into Funnelback.

This configuration file can be used by a system administrator to setup mappings from old v15.24 and earlier style collection IDs to the v16.0 search package/data source IDs.

This enables a Funnelback server to be backwards compatible with any collection IDs that have configured mappings to new IDs.

The mappings are applied to collection IDs and will apply for accesses to all push API and public search endpoints (URLs beneath https://FUNNELABCK-SERVER/s/) including:

  • search.html

  • search.json

  • suggest.json

Collection ID mapping for other endpoints (such as the administration API) is not currently supported.
v15.24 and earlier collection IDs are not unique within v16. If v15.24 and earlier collections are being consolidated from more than one Funnelback server you may end up with conflicting IDs (e.g. two collections called 'staff'). The collection remapping configuration is not able to handle this scenario and a mapping will only be able to be created for one of the v15.24 collection IDs.

Setting up mappings for existing collection IDs

Funnelback 16 adds a concept of a client which has resulted in collection IDs changing (with the collection ID being prefixed with a client ID).

As a result all integrations with Funnelback search or API endpoints will need to be updated to accommodate the new collection IDs.

A system administrator has the option to create individual mappings for the old style collection IDs to new style collection IDs to provide backwards compatibility where client integrations can’t be easily updated.

collection mappings only affect the public search and push API endpoints (administration API endpoints are not currently supported).

Individual mappings are configured using this configuration file.

Use collection mappings to provide backwards compatibility to enable client integrations to be updated without any client downtime. However, it is recommended that the mappings are removed as soon as practical as old-style collection IDs are considered to be deprecated.


The file:


is a file containing key=value pairs similar to collection.cfg (with support for comments) creating a mapping of v15 and earlier collection IDs to v16 search package/data source IDs.


If you wish to have requests for a v15.24 and earlier collection ID foo go to a v16 search package ID or data source ID client~foo the v15collectionremap.cfg file would need an entry:

# Mapping the old foo collection to client~foo

This would result in the following web requests:


being equivalant to: