Migrating from echosign.com to adobesign.com

Overview of what's happening

Adobe Acrobat Sign has deployed a new domain: adobesign.com.

Customer accounts that are currently configured on the echosign.com domain will be migrated to adobesign.com by December of 2022.

Customers can identify their domain by logging in to Acrobat Sign and checking the URL:

Echosign URL

Individual and Free accounts are being migrated automatically, as those tiers of service don't have the complex features that require admin review.

All other tiers of service are targeted to be migrated within the time frames described below:

June 2020

The migration of all free and individual tier accounts to the adobesign.com domain will be completed.

July 2020

All new small business and individual tier accounts will be provisioned on the adobesign.com domain. 

September 2020


All new business tier accounts will be provisioned on the adobesign.com domain.

All existing business tier accounts will have an option to opt-in to the new domain after verifying their account is prepared to migrate.

October 2020


All new enterprise tier accounts will be provisioned on the adobesign.com domain.

Gradually roll out the option to opt-in to the new domain to existing enterprise tier accounts.

December 2022

All accounts should be migrated to the adobesign.com domain by December 2022. The option to switch back to the echosign.com domain will be removed at that time.


Actions to review/take

To ensure continuity of service, customers should prepare for the domain migration by reviewing the below list of actions and addressing the issues that are germane for their account.

All impacted accounts will have the ability to switch to the new domain once their account has successfully resolved any concerns/tasks that the below list prompts.

تحذير:

Changing your SAML configuration requires that you opt-in to the new domain immediately after saving the new IdP settings in Acrobat Sign.

SSO to the account will be broken until the domain switch is completed.

If you are a SAML using customer, be sure to set your SAML Mode settings in Acrobat Sign to SAML Allowed

  • Verify that you know your native Acrobat Sign password
    • This is a precaution to avoid being accidentally locked out of your account after you change the IdP

Admins that have users leveraging the Acrobat Sign for iOS mobile app should alert their users to upgrade their app version to 3.22 or later.

The Acrobat Sign for Android app is not impacted by the domain change.

ملاحظة:

Updating custom email templates must be done by your success manager or the support team.

As the templates can be updated at any time prior to changing to the new domain., it is recommended that you request this update as early as possible.

If your account uses any custom email templates, the template must be updated to allow for a reference to adobesign@adobesign.com as the email alias for users to add to their safe list..

  • To do this, the fixed string echosign@echosign.com is changed to the variable $!from@$!active_domain
    • This allows the address to dynamically change when the account is switched between domains

Customers that actively restrict email should explicitly allow email from adobesign@adobesign.com

  • If you have an existing rule to allow echosign@echosign.com, then add this new rule also
    • Do not remove the echosign@echosign.com rule at this time

Failure to do so could result in inbound (email) agreement notifications being filtered out to spam/junk folders.

Customers with restrictive network security should explicitly allow traffic from the new domain's production endpoints.

If your current network permissions are configured to allow echosign.com traffic through, the adobesign.com endpoints should be added as well.

  • Do not remove the echosign.com endpoints at this time
  • Only add adobesignforsalesforce.com if your account employs the Adobe Acrobat Sign for Salesforce integration
  • Customers that have accounts on the Demo environment should add the adobesign Demo endpoints as well
Environment 'echosign' domain 'adobesign' domain equivalent
Production echosign.com adobesign.com
echocdn.com adobesigncdn.com
echosignforsalesforce.com adobesignforsalesforce.com
-- documentcloud.adobe.com
Demo echosigndemo.com adobesigndemo.com
echocdndemo.com adobesigncdndemo.com
echosignforsalesforcedemo.com adobesignforsalesforcedemo.com
ملاحظة:

An expanded list of Adobe Acrobat Sign endpoints can be found here, but only those listed above are relevant to this domain migration.

No edits to IP ranges are required.

Accounts that leverage the API service should review their code to ensure that it also supports the adobesign.com domain.

ملاحظة:

Refresh tokens (used to get new access tokens) are not tied to the domain, so they are not impacted by the domain change.

Customers/Partners/Integrators may have code that has a hardcoded check for the URI returned. This may be done as a security measure to prevent an exploit which attempts to redirect the domain incorrectly.

  • Contact the owner of any third party integration to determine if this situation exists
  • Contact your internal stakeholders for custom integrations that were built in-house
تحذير:

Changing your SAML configuration requires that you opt-in to the new domain immediately after saving the new IdP settings in Acrobat Sign.

SSO to the account will be broken until the domain switch is completed.

  1. Set your SAML Mode settings in Acrobat Sign to SAML Allowed

    • Verify that you know your native Acrobat Sign password
      • This is a precaution to avoid being accidentally locked out of your account after you change the IdP
    SAML Mode

  2. Create a new client with your IdP (MSADFS, Okta, etc)

    • Build your new client using the Acrobat Sign SAML Service Provider Information for the new domain (See the caution below)
    • It is recommended that you retain the old client until you are confident that SSO is working as expected in the new domain
    تحذير:

    When migrating to a new domain, the Acrobat Sign Service Provider content on the Acrobat Sign SAML page will show the existing domain configuration.

    You need to manually edit the three URLs to reflect the new domain you are migrating to.

    • eg: If you are migrating to adobesign.com, your existing URLs will reflect echosign.com; manually change them to adobesign.com when you configure your new client

    Do not edit the:

    • Entity ID/SAML Audience
    • SP Certificate

    Manually edit the:

    • Assertion Consumer URL
    • Single Logout (SLO) URL
    • Single Sign-On (Login) URL


  3. Update the Identity Provider configurations using the values from the newly created IdP client

  4. Log in to Acrobat Sign as an account-level admin and navigate to Account > Account Settings > Account Setup

    • Click the Update now button
      • You will be logged out automatically and will have to authenticate to the new domain
      • If you have a bookmark to log in, edit the URL to use adobesign.com instead of echosign.com
    Update the domain

    ملاحظة:

    Bookmarks to the old domain (echosign.com) can prompt multiple Cookie enablement requests when the login process shifts the user to the new domain (adobesign.com). 

    Users can mitigate this by updating their bookmarks.

  5. Test your SSO connection

Adobe Acrobat Sign for Salesforce customers must relink the OAuth connection between Acrobat Sign and Salesforce (as soon as possible) after the domain has been changed.

Changing the domain breaks the trusted connection between Acrobat Sign and Salesforce. Until the OAuth link is reconnected:

  • Users will not be able to send agreements from Salesforce
    • Attempts to send will prompt an error and save the agreement as a Draft   
  • Updates will not be pushed back into Salesforce
    • Upon reconnection, the agreements can be updated and resynced with the Acrobat Sign service

Review/Update Remote Site Settings

Organizations that have configured Remote Site Settings for Acrobat Sign must also update the remote site URL to reflect adobesign.com (in place of echosign.com).

  1. Navigate to Setup > Settings > Security > Remote Site Settings

  2. Review the Remote Site URLs for the remote sites configured.

    Find any sites that use echosign.com as the domain in the URL:

    Update the remote site URL

  3. Click the Edit action for the remote site using the echosign.com domain

  4. Edit the Remote Site URL and change echosign.com to adobesign.com

    Update the remote site URL

    تحذير:

    Do not change the other elements of the URL.

  5. Click Save to save the new configuration

Repeat steps 3-5 for all remote sites that use echosign.com as the domain for the URL.

Note that it is possible for the site URL to contain the string "echosign" in a location of the string that is not the domain. Do NOT edit these values:

Not an echosign.com domain

Existing web forms will continue to work as expected after changing the domain.

When a web form is created, it is identified by a unique webformId (wid).

Changing the domain changes the URL of the web form, but not the webformId.

Example:

The echosign.com webform URL:

  • https://caseyjonez.na1.echosign.com/public/esignWidget?wid=CBFi_MHTdBzgM82U*

The same web form after the domain change:

  • https://caseyjonez.na1.adobesign.com/public/esignWidget?wid=CBFi_MHTdBzgM82U*

Because Acrobat Sign continues to accept inbound traffic on the echosign.com domain, the URL resolves and the correct webformId is delivered.

ملاحظة:

It is recommended that customers update their content to use the URLs with the new domain when possible.

ملاحظة:

All accounts are strongly encouraged to "opt-in" to the new domain as early as possible to allow time for troubleshooting if problems arise.

Accounts can switch back to the legacy domain if problems do occur. 


How to change the domain

When you are satisfied that your account is ready to migrate:

  1. Log in to Acrobat Sign as an account-level administrator

  2. Navigate to Account > Account Settings > Account Setup

  3. Click the Update now button

    Update the domain

  4. A check list of the important actions is presented in an overlay.

    Review each point and check them off when you are confident the concern is properly addressed for your account.

    Verify checklist

  5. Click OK when all of the boxes are checked, and then click Save:

    • You will be logged out automatically, and will have to authenticate to the new domain
    • If you have a bookmark to log in, edit the URL to use adobesign.com instead of echosign.com
    ملاحظة:

    Bookmarks to the old domain (echosign.com) can prompt multiple Cookie enablement requests when the login process shifts the user to the new domain (adobesign.com). 

    It is recommended that users be notified to update their bookmarks to target the new login domain.


Revert back to the legacy domain

If you have to revert back to the legacy domain for any reason, the process is the same as the initial switch.

  • Accounts that have SAML enabled will need to re-configure their SAML IdP settings to use the old client
  • Accounts that employ the Adobe Acrobat Sign for Salesforce integration will need to re-link the applications after the switch
  1. Log in to Acrobat Sign as an account-level administrator

  2. Navigate to Account > Account Settings > Account Setup

  3. Click the Update now button, and then click Save

    • You will be logged out automatically
    Update the domain


Common questions

Below you will find a list of common questions about the domain migration.

If you can not find an answer for your question here, please contact your success manager or customer support.

Case: Account migrated to adobesign.com domain - API call made using echosign.com domain

  • Sample Request URL:  https://api.na2.echosign.com/api/rest/v6/baseUris
  • Sample Response

{

  "apiAccessPoint": "https://api.na2.adobesign.com/",

  "webAccessPoint": "https://secure.na2.adobesign.com/"

}

ملاحظة:

The domain in the sample response, points to adobesign.com even if the request was made from echosign.com.

  • If you check the response for echosign.com, then your check will fail
    • Replace the echosign.com hostname to adobesign.com if there are any hardcoded cases

Case: Account migrated to adobesign.com domain - API call made using adobesign.com domain

  • Sample Request URL:  https://api.na2.adobesign.com:443/api/rest/v6/baseUris
  • Sample Response

1

2

3

4

{

  "apiAccessPoint": "https://api.na2.adobesign.com/",

  "webAccessPoint": "https://secure.na2.adobesign.com/"

}

No.

Accounts on any *.documents.adobe.com URL are not being migrated.

Only accounts on the *.echosign.com domain are being migrated to the adobesign.com domain. 

No.

The same IP ranges (listed on the system requirements page) are being used for the adobesign.com domain.

Nothing new is being added; nothing is being removed.

شعار Adobe

تسجيل الدخول إلى حسابك