Migrate from OLD SDE Server to New One

[ericmeyers1]

We currently have an ArcSDE server here at the city that we will be replacing. We are currently in the stages of building a new SDE server and want to replace the old one as smoothly as possible with little to no down time. We've been informed by ESRI and some of our IT staff that it can easily be done by installing a SQL Server instance with the same name as our current instance and switching over the server names. For example GISSDE > GISSDE2. Basically we mirror the old machine and then switch the machines so that we are not forced in having to update all of the backend links for all our of map services, projects, apps, etc. Can anyone provide and insight regarding a business process like this?

Thanks!

[RebeccaStrauch__GISP]

Are you switching versions of SQL (I'm assuming)?  How about ArcGIS versions?

The connection file format changes some between ArcGIS Versions.  Also, sometimes python and other commands require the owner (e.g. DBO) in the path name and sometimes not.  That is nothing you have to worry about unless you have scripts that run, but something to be aware of.

From my experience, the actual server name isn't as critical as the connection file you use.  In theory, if a new connection file is setup to the new instance, but the connection file was named the same, it may just work.So at least for testing, and before renaming both servers, I would try creating the new instance on the new machine, renaming the old connection file as a backup, set up the new connection with the same name and test to see if there are issues.  I like to keep both machines running, just in case, until I have things test on the new. That's just my thoughts....

[ericmeyers1]

We are upgrading from 2008 R2 to 2012 and moving from ArcGIS10.1 to 10.3

We are trying to avoid changing/renaming connection files. We've heard from some IT staff that it may be impossible to name the SQL Server Instance the same name as one currently on the server. If that is true, it is going to be tough to switch the SQL Servers even if we can swap the machine names.

Also, do you have any suggestions on C:/ - D:/ allocation space/recommendations. I believe our old server had the following ratio C:/419GB - D:2.04TB. Our new box will be double that.

[VinceAngelo]

It's not important to keep the server name similar, but it is critical to keep the database name(s) the same.

There are a number of ways to get a backup installed on the new server, but the one I've used is:

1. Detach the database
2. Copy the datafiles to the new server
3. Reattach the datafiles to the old server (old server is now live)
4. Attach the datafiles to a database with the same name on the new server
5. Use sp_change_users_login to repair the login ids for the new database
6. Upgrade the database (if going from 2008 to 2012)
7. Upgrade the geodatabase (if changing ArcGIS versions)
8. Test, test, test until you're sure everything is fine
9. Let trailblazers start working on the new server
10. When ready, shutdown the old server (or reboot with a new IP)  and reboot the new one with a changed IP address.

You can even go several passes at this process, until you feel comfortable leaving the old server offline.

- V

[George_Thompson]

Here is some help documentation on what Vince was referring to in his post.

Methods to move a geodatabase in SQL Server—Help | ArcGIS for Desktop

-George

Geodatabase

[ericmeyers1]

When you say server name NOT critical, are you talking about SQL or Windows? We are not going to change the Database name & the feature classes within it but would like to prevent our organization from having to modify/change connection files. If the SQL Server is named differently, then all the connection files would essentially have to be changed, right? When you ODBC to a database it goes something like [GISSDE].{SDETRANS].[DBO].[DATA] and that first part (server name) would be different and we have to avoid that.

Also, do you have any suggestions on C:/ - D:/ allocation space/recommendations. I believe our old server had the following ratio C:/419GB - D:2.04TB. Our new box will be double that.

[George_Thompson]

Hi Eric,

The name of the server could be changed, it is just the database name on the SQL Server instance cannot be changed. You may have to update the connection files unless IT can re-name the new machine with the same name.

As for suggestions on allocation space or requirements, that is a very tough question to answer. I would review the minimum requirements/best practices for MS SQL Server. ArcGIS Enterprise geodatabases typically do not care how or where the data is stored, this is all managed by the RDBMS software and not ArcGIS.

[JohnFannon · Accepted solution]

If you want to avoid users updating their database connections, then I think the only way to do this would be to:

1) Create a new server with the same name (but perhaps not on the same network/domain initially).

2) Install SQL Server and use the same instance name.

3) Back up and restore the database from the old server to the new server.

4) Optionally upgrade the geodatabase to the latest version (your backup will still be the same geodatabase. Version as the old system - i.e. 10.1)

5) Take the old server off the network/domain and then add the new server to the network/domain

As you say, the server name is embedded in the connection, so if the new server does not have the same name, then the old connections won't work.

John

[ericmeyers1]

This process worked successfully without any issues. I was able to create a second version of our SDE DB and when ready, swap the two.

EX. SDE1 & SDE2

Once SDE2 is in sync with SDE1, drop both servers from the network, and swap the IP/host names. Finally, within SQL swap the server name.

NOTE: this will only work if you kept the instance name for SQL server the same as default (MSSQLSERVER)

<server>/<instance>

ArcGIS calls a ODBC connection to the instance name but that is incorrect, you are connecting to the server name, not the instance.

Let me know if you have any questions regarding what we did but everything worked smoothly without having to repair any broken links in a matter of 20 minutes.

[bsanders69]

Thank you for your post!  We are a City and have been in an ArcGIS Enterprise for several years now since 10.4 and have amassed a very large number of map content for almost every department.  Every ArcMap file and Pro project ODBC database connection that has been used to publish services would need to be fixed and re-published.  Then...every web map and their  layer pop-ups, apps and dashboards that would need to be recreated or rebuilt, is weeks worth of work that could be avoided by not breaking the ODBC connections in the first place.  We are in a virtual world (VMware), so this process is even easier than individual machines.  If it doesn't work the first time, we can always just reattach the old SQL Server machine back to the domain and try again.  We also have the ability to generate snapshots that will put servers back to their exact state before any mods were done in case we miss a step.