A listener copied inside one tenant, or moved from sandbox to production, copies the setup you saved. It also copies a setup that is already wrong. Check the listener in the source tenant before you copy it.
Sandbox to production
The supported way to move a listener to another tenant is the Transfer Configuration Connection, from the source tenant.
On the source tenant, create a Transfer Configuration connection and add the production tenant (hostname, public client ID, and client secret from Settings > Access management > Applications on production).
Add a Sync configuration goal and add the listener.
Click Analyze before Transfer. Read each related row. Create means production does not have it yet. Found means a profile property with that same ID already exists and will be reused. Not found means the listener will point at something production does not have.
Transfer only after the analysis matches what you expect. The transfer overwrites a listener on the target that the goal updates. It does not roll back.
Copying inside one tenant (Duplicate on the listener) is a different action. It makes a second listener on that same tenant. It does not create the listener on production.
What carries over
The listener type, name, on/off state, Where rules, and the rules you configured (parameters, funnel steps, form selectors, interest terms).
References to profile properties, by the property ID.
Related objects the transfer analysis lists, when you let it create them.
What does not carry over
Profiles, and any values already collected. The new tenant starts empty for that listener.
The listener’s activity history, including Last activated.
A guarantee that the listener ID stays the same. Inside one tenant, a duplicate has a new ID. Across tenants, merge-by-name can attach to an existing listener with the same name, and “always create” makes a new one. Profile properties are the exception: they match on their ID. A property ID that already exists on production is reused and is not replaced by the source definition.
Plugins that are missing or older on production. The analysis blocks a transfer that would downgrade a plugin. Install the plugin on production first. The Visit Listener is an external plugin and must be registered on the target tenant before a transferred listener of that type can run.
A broken setup is copied too
If parameter rows are empty, a funnel has no completion step, or a form selector points at a test page, that is what production receives.
Two cases that look like the move failed:
Campaign Tracker. A copied listener can lose its parameter mapping the next time you edit and save it. Create a new Campaign Tracker on the target and add the parameters there, instead of repairing the copy.
Profile property IDs. The listener still names
visits_ranged_90. If production already has a different property for that purpose, the listener does not switch over by itself. Either let the transfer create the source property, or point the listener at the production property after the move.
After the transfer, open the listener on production, confirm Where, the property mapping, and visitor Write on those properties, then run one test visit before you turn it on for everyone.