Moving an Installation of mojoPortal to a Different Server

Moving an Installation of mojoPortal to a Different Server

People often ask how to move an installation of mojoPortal content management system  from their local machine to a production machine or hosting provider, so this document is meant to address this and provide tips to make it easier. The same steps are required when moving from one production server or host to another.

Do NOT complicate the move to a new server by trying to upgrade at the same time. If you want to upgrade wait until after you've moved it and the site is working correctly, then back up everything and proceed with the upgrade, or else upgrade first in your current hosting and make sure it is working well before moving.

The URL Structure Needs to Be the Same in Both Environments

If you decide to populate the content of a mojoPortal site one one machine and then later move it along with content to another machine, it is very important that the URL structure is the same on your local machine as it will be on your production site. A common mistake that people make is they set up the site on their local machine as a virtual directory like http://localhost/mojoportal/ and then they add a bunch of content and want to move it to a hosted environment as a root level site like http://www.somedomain.com. Images entered into the content system use relative URLs in order to make it possible to move a site and its content even if the domain name changes. What people fail to realize is that relative URLs are always relative to the root of the site not to the root of the virtual directory. So if you create content on your machine using the URL http://localhost/mojoportal, and you add images, the URLs created for the images will be of the form /mojoportal/somefolder/someimage.png because the virtual folder mojoportal is part of the relative path from the root of the site. So then when you move to a hosted site the URLs for images will be broken because they still have the /mojoportal part in the URL and this is not the correct path now that the site is running at the root web site level instead of a virtual directory. If the site were running in a virtual directory with the same name on production it will work. For example if you install it at http://www.somedomain.com/mojoportal, then it would have a matching URL structure and it would work. But the most common scenario is to install it as a root level site so if you want to add content and images from your local machine you should run it on your local machine as a root site directly at http://localhost. If you make this mistake and create a lot of content with images, you will have a lot of work to do to correct it after you move it to production because you would have to manually edit the image URLs to remove the extra /mojoportal segment.

Steps to Move a Site

  1. Create a backup of your database on the source machine and restore it on the target machine. A common newbie mistake here is that people try to just import the tables from one database to another. That does not work--you lose all primary keys, foreign keys, and indexes; and it fails to get the stored procedures. You must restore the backup using the tools provided by the database platform like SQL Management Studio or whatever tools your host may provide. If for some reason it is not possible to restore a backup, you may also be able to use this tool to script off all the objects and data into a script that can be run on the target machine. Then you could run this script in a new empty database to restore all the database objects and data.
  2. Copy all the contents (files and folders) from your source web site root to the root of the site on the target. Ideally you may be able to create a .zip file on the source machine, transfer the zip, then decompress it on the target.
  3. On the target, delete any temporary files that were created on your source machine. Specifically, delete all the files from /Data/systemfiles and from /Data/Sites/[SiteID]/systemfiles
  4. Re-establish correct folder permissions so that only the /Data and /App_Data folders are writable by the web process, and all other files and folders are read-only.
  5. Set your connection string for the new database in the target machine's Web.config or ideally in user.config.

Assuming the target site has the correct version of ASP.NET, that should be all the steps needed. Note that if you set your connection string in user.config, you need to touch Web.config so it reloads the settings. If you get security errors it probably means you need to configure for Medium Trust or that you have not correctly configured file permissions. For further assistance, see the Basic Troubleshooting document, and if after going through that you are still stuck, post in the forum.

Last Updated 2011-06-13 by Jamie Eubanks