Platform Migration: Customer Action Guide

Your Sharpen organization is being moved to our current production environment on your scheduled cutover date. Your account itself does not change — your company, your users, your queues, and your credentials all carry over unchanged, and Sharpen moves your phone numbers for you at the carrier level.

What changes are the web addresses used to reach Sharpen. Anywhere you have stored, bookmarked, embedded, or hard-coded a Sharpen URL — in your website, your CRM, your own code, a firewall rule, a desk phone, or a browser bookmark — that address must be updated.

The most important thing to understand: the web address decides which environment you reach — your credentials do not. If an old address is left in place, your requests keep going to the old environment.

Start with the Frequently Asked Questions below. Each numbered section that follows begins with "If you…" so you can skip what does not apply to your organization, and a summary checklist appears at the end.

1. Sharpen Migration Team performs a full IZ0 to IZ1 migration of data and configuration.

2. Sharpen Migration Team reviews back-end functionality, and prepares environment in IZ1 for testing.

3. Sharpen Migration Team provides a new or moved Test phonenumber to Customer to test high-value call flows, features, and integrations.

4. UAT communication is coordinated in dedicated Migration zendesk ticket.

   1. Sharpen Care tickets may be referenced

5. UAT Concludes, cut-over date is scheduled

6. Cutover (All phone numbers, integrations, agents, are logged in and pointed to IZ1).

What is my URL to log in?

Sign in at https://app.iz1.sharpencx.com. Please update your bookmarks, saved shortcuts, and any internal documentation that points staff to the old address.

Do my username and password change?

No. Your username and password stay exactly the same.

Do my API keys change?

No. Your V2 keys (cKey1 and cKey2) and your V1 API key and secret all carry over unchanged. Only the web address in your requests changes.

Do I need to do anything with my phone numbers?

No. Sharpen moves your phone numbers for you at the carrier level, and they keep working exactly as they do today.

Do my queues, extensions, and agent logins change?

No. Queue names, queue extensions, user group names, and agent usernames all stay the same.

Have I reviewed my account with my Sharpen team?

Your Sharpen team will walk through your account with you before your cutover date so you know what to expect on the day. Bring whoever knows your day-to-day setup best.

Have I checked my Integrations page in Sharpen?

Open your Integrations page and confirm the connections listed there are still ones you use. Let your Sharpen team know if any should be retired instead of moved.

Have I checked my external applications that interact with Sharpen?

Anything outside Sharpen that connects to your account — Salesforce, HubSpot, a custom CRM, reporting tools, or your own automations — needs its address updated. Section 3 lists every old address and its replacement.

Do I need to change anything for inbound email?

Yes, if you forward a mailbox into a Sharpen queue. Each queue's inbox address gets a new domain, so your forwarding rule needs updating at cutover. Section 10 has the details.

Is my chat widget updated on my website?

If you have Sharpen Chat embedded anywhere, the loader address and the appKey need to be updated together. Section 2 has the details.

Do I need to update my desk phones?

If you use Polycom or Yealink desk phones, they need to be pointed at the new provisioning server as described in section 9. If your team uses the Sharpen Q browser phone, there is nothing to do; signing in at the new address is all that is needed.

Does my IT team need to make any network changes?

Yes. Your new environment uses new domains, so they need to be added to your firewall, proxy, or web filter allowlist. Everything your network team needs is in Network Requirements and Workstation Requirements.

What should my team check on day one?

Sign in at the new address, place an outbound call, take an inbound call, start a chat, play back a recording, and load a wallboard or report. Let your Sharpen team know right away if anything looks off.

If you or your team sign in to Sharpen, or have the login page bookmarked…

Update saved bookmarks, browser-saved passwords, internal wiki and onboarding documents, and any desktop or intranet shortcut you have distributed to staff.

If you have Sharpen Chat embedded on any website, landing page, or in a CMS…

Changing only the appKey is not enough. The loader address is what selects the environment — the widget has its endpoints built in. If you swap the key but leave src="https://chat.sharpen.cx", your chat keeps running against the old environment no matter which key you use. Both attributes must change together.

Also please check:

• Every page and every property, not just your homepage. Each chat theme is a separate embed with its own key, especially important with multiple chat flows.

• Whether the snippet is in page code or in a CMS script manager. If it is a CMS entry, this is a content edit with both fields in one place. If it is hard-coded, it needs a web release — plan accordingly.

• Your custom chat styling. If your site CSS targets the widget's internal elements (#sharpenChat, #chatWindow, #chatEntryWindow), review the widget's appearance after the change — desktop and mobile, collapsed bubble and open window. Chat can be fully functional while looking unstyled, so a "does chat work?" test will not catch this.

• Copy these two addresses exactly as written. Both end in sharpen.cx, not sharpencx.com — unlike the API and login addresses. The sharpencx.com versions of the chat loader and socket do not exist, and a request to one simply fails to connect.

If you or a vendor call the Sharpen API from your own code, scripts, iPaaS platform, or reporting tools…

Your API credentials do not change. Both your V2 keys (cKey1 / cKey2) and your V1 API key and secret (X-API-KEY / X-API-SECRET) are carried over to the new environment and continue to work as-is. Only the base address in your requests changes — No need to replace your credentials.

Older integrations frequently use one of the bottom four addresses rather than an iz0 one. Please search your code and configuration for every name in the left column, including fathomvoice.com — that domain is retired, is tied to the old environment, and is the most common thing left behind after a migration.

Address spellings. legacy-api.iz1.sharpencx.com and api-current.iz1.sharpen.cx are the same endpoint; api-gateway.iz1.sharpencx.com and api.iz1.sharpen.cx are likewise the same. Please use the sharpencx.com spellings in the table above and use them consistently. Do not use api.iz1.sharpen.cx for /V2/ requests — it is the V1 gateway and will return a misleading error.

If a V1 request fails to authenticate immediately after cutover, contact your Sharpen team rather than creating a new key. Credentials are copied as part of the migration. A replacement key is rarely the right fix.

If you configured a Sharpen webhook URL inside Salesforce, Zendesk, or your own application…

These URLs live in your systems, so no change on the Sharpen side updates them. Look for any Sharpen address in your CRM's outbound messages, flows, triggers, or workflow rules.

A host change alone may not be sufficient for CRM integrations.

• You may need to approve the new address. In Salesforce, add legacy-api.iz1.sharpencx.com to Remote Site Settings, or update the Named Credential your integration uses. In Zendesk, update the webhook or target.

• Update the callback address, if Sharpen is registered as an app. If Sharpen is set up as a connected app or OAuth client inside your CRM, the callback address stored there still points at the old environment, and the new address needs to be added.

If you link to, or call, a Sharpen CX project from outside Sharpen — a form action, a website button, or another vendor's system…

Your project key stays the same — only the domain changes. Please tell your Sharpen team about any externally-referenced project URL so it can be confirmed as responding in the new environment before you cut over. Include staging and test sites: -dev addresses are easy to overlook.

If you have a wallboard on a TV, a bookmarked Agent Vue, or a saved reporting link…

These are typically loaded on dedicated display machines or from personal bookmarks rather than by navigating the app, so they are rarely rediscovered on their own. Please inventory every kiosk, TV, and shared bookmark before cutover. Note that the assets address ends in sharpen.cx — there is no assets.iz1.sharpencx.com.

If you save Sharpen ID numbers or links into your CRM, reports, data warehouse, or archives…

Some Sharpen ID numbers are reassigned in the new environment. Your names, keys, extensions, and phone numbers do not change — but the numeric IDs below do.

Saved links to individual interactions will no longer open. An interaction ID from the old environment does not exist in the new one, so a stored link such as app.iz1.sharpencx.com/contactCard/36453158 will fail to load if that ID came from the old environment. This affects interaction links you have pasted into CRM records, tickets, emails, or spreadsheets.

Scripts that call a Sharpen Table by number will stop finding it. If your code, a Postman collection, or an integration reads or writes a Sharpen Table using its numeric ID, it will return "Object not found" in the new environment. Switch those references to the table's API name — for example Accounts__api — which does not change. If you cannot switch to the API name, ask your Sharpen team for a list of your old and new table IDs.

Your historical data and recordings are not lost — only the stored links and ID numbers stop resolving. If you report across the cutover date, match on business attributes such as phone number plus date and time rather than on Sharpen ID numbers, and expect a seam at the cutover date.

If your network, firewall, proxy, or content filter restricts which domains your agents can reach…

The new environment is separate infrastructure on different addresses, so allowing the old domains is not sufficient. Replace the zone-specific entries below. The global entries (*.s3.amazonaws.com, the Google STUN servers, and the font, logging, and analytics libraries) are unchanged and must remain allowed.

Both *.iz1.sharpencx.com and *.iz1.sharpen.cx are required. Allowing only one is a common cause of hard-to-diagnose partial failures — chat, agent photos, and the survey app are served exclusively from sharpen.cx, while other services use sharpencx.com. If you already allow both wildcards, no further firewall change is needed.

For the full specification — including workstation hardware, browser support, supported IP phones, network performance thresholds, and common issues such as SIP ALG — see Network Requirements, Workstation Requirements, and Platform Requirements. Please review these with whoever manages your network before cutover.

If you use Polycom or Yealink desk phones…

If your team uses only the Sharpen Q browser phone, no action is needed. Signing in at https://app.iz1.sharpencx.com is all that is required — the browser phone follows automatically. You can skip this section.

Your desk phones download their configuration from a provisioning server each time they start up, and that server has a new address. You need to update either the address stored in each phone or the address your DHCP server hands out. Your previous address was similar to provision.fathomvoice.com/phone/polycom.

Please complete this just before your cutover date if you have not already. Your provisioning URLs are specific to your account, so request them from the Sharpen Care team rather than copying a URL from anyone else's instructions. Polycom and Yealink phones use different URLs, and there is an HTTPS address and a separate HTTP fallback address for older phones.

Two things worth knowing:

• Test one phone by hand before you change DHCP. A DHCP change affects every phone at once, so please confirm the new address works on a single phone — registered, outbound call, inbound call, after a deliberate reboot — before rolling out.

• A wrong address often fails silently. A phone that cannot reach its provisioning server usually keeps running the configuration it already has, so it can appear fine for days and then fail the next time it restarts.

Full instructions, including the per-brand menu paths, the HTTPS-first test procedure, and DHCP cautions: Updating Your Phone to Sharpen's new Provisioning Server (IZ1).

If you forward a mailbox, such as support@yourcompany.com, into a Sharpen queue…

For example, ABC123DEF4567@sharpenmail.net becomes ABC123DEF4567@sharpenmail.iz1.sharpen.cx. The part before the @ stays the same. Only the domain changes.

This change is made in your email system, not in Sharpen. Update the forwarding rule, alias, or transport rule in Microsoft 365, Google Workspace, or your mail server on your cutover date.

Also check:

• Every forwarded mailbox. Each queue has its own inbox address, so update a rule for each mailbox you forward.

• Approved forwarding domains. If your email system only forwards to approved outside domains, add sharpenmail.iz1.sharpen.cx.

• Verification emails. Some providers send a confirmation code to a new forwarding address before they turn it on. That message arrives in your Sharpen queue, so have an agent ready to pass it along.

• Copy the domain exactly. Queue Emails end in sharpen.cx, not sharpencx.com as of this migration project.

The following depend on how your organization is configured.

• Single sign-on (SSO / SAML). If your users sign in through Okta, Microsoft Entra, or Google, the login address changes — so your identity provider's Sharpen application may need its reply / ACS URL updated. Confirm the exact values before cutover; SSO is on the critical path for every user. Related: Single Sign-On in Sharpen and Configuring OKTA in Sharpen.

• Allowlists keyed to IP addresses rather than domains. We recommend allowlisting by domain, as in section 8, because our addresses can change without advance notice. If your network or a partner's system restricts by specific IP address instead, the current ranges for both environments are published in Network Requirements — please confirm them with us before cutover.

• Your own SIP carrier (BYOC). Ensure UAT testing has confirmed BYOC SIP trunk functionality on the new environment.

  • Outbound SIP Trunk Requirements

  • Inbound SIP Trunk Requirements

Nothing in this guide requires you to change your username, password, API keys, or phone numbers. If you are unsure whether an item applies to your organization, contact your Sharpen team before cutover.

This article is part of a series on Platform Resources & Troubleshooting topics.

Click here to access additional articles and topics.