Hi Catherine, I started my email describing all the options for content migration and there are so many that it quickly got incomprehensible. So I started over and I'll describe only the way I recommend for whole server migration (db dump+copy assetstore), after all, you asked only for best practice. The rest are were rather options suitable for backup/restore.
> 1. Instance including all of the content (ie bitstreams) – basically a > full replication from one server to another. You still have 2 overall options here: a) Copy over your whole [dspace] directory from the old/development server, adjust a few configuration properties + dump and restore the database b) Deploy from the same source (incl. customizations and configuration) as you deploy on the old/development server + dump and restore the database + copy over the assetstore It's really up to you to decide which of these 2 approaches to take, they work equally well. The few config properties I'm talking about, in which the old server will differ from the new are all included in this file (which was introduced in 3.0 to make building for several environments like dev/staging/production easier): https://github.com/DSpace/DSpace/blob/dspace-3_x/build.properties With option a) you can just modify them directly in dspace.cfg. With option b) you can actually leverage build.properties to deploy to several environments from the same source. > 2. Instance including no items or bitstreams, but all of the > Communities and Collections. Basically the “structure” without items. You still can got the a) or b) route, leaving out the contents (assetstore and database contents). The complication here is that database contains not only items, but also users and groups (and schema definition, file types and harvested collections, if you modified any of it). So you have to choose whether you want to start with a clean database or migrate the database, deleting all the items from it (in DSpace, old or new). But there's here's just the tool for the job: https://wiki.duraspace.org/display/DSDOC3x/Importing+Community+and+Collection+Hierarchy Just remember that it will not export/import any premissions you set on collections or any community administrators/managers you assigned. Furthermore, I disagree with Christian that this is just useful once in a lifetime of an instance. It can actually be less work to do it this way when upgrading DSpace and you want to give the new version proper testing while the old one is running in production. It can be also easier (and less downtime) when you're doing a major upgrade of the underlying OS to prepare it on a new machine than to potentially break the production machine. After all, Christian also described this use case in his last paragraph. I'll be happy to clear up any details or questions. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
