Overwrite referenced layer in new environment

[moremeowbell]

Hello all!

We just deployed a new version of ArcGIS Enterprise 11.4 in a new environment. I am having an issue overwriting a referenced layer on Portal using ArcGIS Pro. 

In our old environment, we were using an AWS Aurora database to publish referenced data to Portal without issue. However, in our new environment we are using a different AWS Aurora database due to a VPC change. The datasets in our new Arcgis Enterprise environment were migrated over with the old database references. When I attempt to overwrite the old services/layers with data from the new database, I am getting an error.

System Changes:

• Arcgis Enterprise 10.9.1 => Arcgis Enterprise 11.4
• Linux OS => Windows OS
• New cloud database (AWS Aurora) on different VPC

Error Message from ArcGIS Pro:

ArcGIS Pro error message

[Leena_Abdulqader]

Hi @moremeowbell hope you are well.

You might have checked this, but if you didn't it's worth checking:

https://support.esri.com/en-us/knowledge-base/error-unable-to-retrieve-the-information-for-existing-...

Let me know if it works🤩

[codethemap]

You can try:

1. If overwrite is blocked due to source mismatch: Re-publish the Service as New

2. If you must overwrite: Recreate the database connection (.sde) using the exact same name and credentials as used in the old environment. (Ensure the database is registered with the new ArcGIS Server using this connection)

Few Checks:
-> Confirm ArcGIS Pro is signed into the correct Portal

-> Make sure the service is still hosted on the same federated server in the new environment.

-> Ensure SSL/TLS, proxy, or firewall settings aren't blocking access to the new DB.

[moremeowbell]

We are attempting to reconnect some 1,000 services, so an overwrite is preferable. However, the services' metadata references an old database that is no longer available to our environment. We have a new database that holds the data now and an updated .sde connection file. I was hoping that we could overwrite the services in order to keep the same portal ids.

It seems the issue is the new database and its new connection string.