So I'm a GIS Intern for a city government, we are preparing to purchase ArcSDE and implement it to our current GIS setup. I'm curious as to what should be done before it is purchased. Our GIS consists of several file geodatabases for parcels, road centerlines, hydrology, etc. as well as several other purposes. As well as shapefiles for the previously listed.

So the question is, for experienced ArcSDE users out there, is there any sort of preprocessing/preparation work I should do before trying to implement ArcSDE? Any tips would be greatly appreciated.

Yeah I've tried looking around for tutorials and things and can't find any useful sources :(. I'm asking about making changes to feature classes or to the file geodatabases themselves. I wanna say we are getting Enterprise and plan on doing Check-In/Check-Out replication

We are currently using ArcGIS Desktop 10.2.1

closed as too broad by PolyGeo, Simbamangu, Fezter, Paul, BradHards Mar 15 '14 at 6:12

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I applaud the effort of trying to research this, but I think you need to still refine your question a bit more. Are you asking if there is anything you need to do to your data (feature classes, tables, etc...) before you get SDE so you can migrate them efficiently? Are you asking if you should re-design your database when you migrate or not? Are you asking what technical processes, server functionality being turned on, network setting prep, etc... you should do before getting SDE? Also, are you getting Workgroup or Enterprise server, and what database (SQL Server, Oracle, PostGIS, etc...)? – John Mar 13 '14 at 22:19

This is a very broad Question but I came across a document titled Migration of GIS Data to ArcSDE from the Connecticut Department of Environmental Protection that might give you some ideas on one aspect you may wish to consider which is change management for existing system users.


I would approach this from the point of "What do we need to know or do to transition our data (to any system)?". The end point is actually somewhat immaterial. The most important things to understand, deeply, is what is your data, and what kinds of questions and operations does your organization need it to be able to answer?

It can be helpful to start at the end and work backwards.

For instance, on our maps we want to draw jurisdictional boundaries differently according to class: an international border is dot-dot-dash, provincial/state borders are dash-dot-dash, districts are..., county are..., etc. etc. One method is to have each one in it's own feature class, but that's crude and duplication of effort. There are more layers to deal with in the map table of contents and in the database, and when one border changes, you have to edit multiple layers so they all match again. Far better to have them all in a single feature class, with attributes structured to support the symbology wanted. The term for this exercise is geodatabase design (or just database design, 'cause spatial isn't special).

One can just lump everything they have into a file geodatabase or two and from there pretty much ingest straight into the ArcGIS Server relational database store (this phrase is the answer to the question, as stated), but the organization would be stepping over a great opportunity to investigate and understand its data and processes, and apply the insights gained in the exercise to improving workflow and data structure. (Process is often overlooked. It shouldn't be.)

A perusal of the tag questions may be helpful.


Ok, this isn't an entire answer, as there are a lot of considerations when engaging in database design (see one of the other answers for explanation of this concept), but a few things that jump out at me to make sure to consider:

  • What, if any, security configuration are you going to need. If, for example, you are going to have some datasets that you want your roads department to be able to edit and everyone else just see but not edit, and you have some datasets for the police department that only select people/departments should even be able to see, and you have other data where ... then you should look at carefully grouping your feature classes into feature datasets with these security needs in mind as it can be relatively easy to set database permissions at the feature dataset level.
  • What, if any, complex datasets, such as geometric networks, topology, network datasets, parcel fabric, etc... are you going to decide to use. If you are going to use any of these, you need to do your research on them to best determine how you should organize your data to facilitate this. Many of these, for example, may require all of the participating feature classes to be in the same feature dataset.
  • Are you going to have data you want to put in the SDE database that you will not want to version? If so, this should be a database design consideration as you generally enable versioning at the feature dataset level. It is not always necessary to version your entire database, especially for large static datasets such as raster data. Furthermore, you need to decide, for these datasets, if it is even appropriate or necessary to have them in the SDE database.
  • Do you have any third party applications, scripts, tools, etc... that you would like to integrate with or connect to your GIS database that will impose specific database schema requirements, either in terms of organization of data, names of feature classes/field names, etc...? You may also be able to look into if customization of these tools is available to allow you to use your own database design; but that may run into financial and/or staff development time limitations. Also, along this same line, you may want to explore applications, tools, templates, etc... you are not currently using but you may want to start using, for example, you may want to research the ArcGIS Local Government database model as that is a database they've built a lot of templates, maps, apps etc... for that work with that particular database model and if you could migrate your data to that model, it may expedite implementation of new functionality using those templates.
  • What are your time and resource constraints on this project? Taking your current file geodatabases and basically just dumping them as is into SDE databases would obviously be relatively quick and simple and would allow for existing staff to continue to use, ideally with minimal re-training. However, if you have the time, you may want to look into more in-depth re-design of your databases as part of the migration, but know that it will take additional time to get existing staff re-trained on where datasets they are familiar with have been moved to and to re-build or adjust existing MXD's (if you had a MXD with roads symbolized based on XYZ field and had a bunch of custom definition queries or custom labeling and you change field names for example, that could take some time to re-set-up).

I know there are other issues you may want to look into, but I hope that at least gets you started thinking about some of the matters that may be of importance to you during the migration. And don't be afraid to ask more specific questions as you begin the migration it self.

Not the answer you're looking for? Browse other questions tagged or ask your own question.