Using FogBugz On Demand? We've recently rolled out a new sidebar as part of taking FogBugz forward. Please see this article for details on what's new, what's changed, and where you can find all your favorite things.

We offer attended migrations of your existing For Your Server data to FogBugz On Site, typically during our normal business hours (9AM to 5PM Eastern, Monday to Friday). If you’d prefer to migrate your data yourself, great! The following outlines that process, with minimal help from us.

Please note that this document applies to customers already using SQL Server. To import a MySQL database, you’ll need to first convert to SQL Server.

Getting Started

With proper preparation, migrating data to FogBugz On Site can be accomplished with minimal downtime.

  1. Before your scheduled migration date and if you’re using an earlier version than 8.18.5 then send us the schema of your FogBugz database. We will generate a SQL script to correct any schema drift that may not be automatically handled during the migration.
  2. Make sure a SQL Server backup of the FogBugz For Your Server database is available locally on the FogBugz On Site database server. For reduced downtime, we recommend moving the FYS database to your new server before the migration to On Site.
  3. InstalInstall FogBugz On Site. For reduced downtime, do this ahead of your migration date.

Migrating the Data

  1. Stop IIS on both the FogBugz On Site and For Your Server web servers
  2. Restore the FogBugz For Your Server SQL Server backup over the top of the appropriate FogBugz On Site database (see below) — or simply rename the databases if they are on the same server already. If this is the first site you are migrating data for, you’ll want to restore your For Your Server data over the trial1 database (the trial number will be different if you have multiple On Site sites running on the same server). If this is an additional site that is being migrated in addition to an existing site in FogBugz On Site, the database name will be trial2 or higher — the highest trial number is the most recently configured site.
  3. Ensure the FogBugz On Site database user is mapped as db_owner on the new trial database.
  4. Disable active mailboxes. This gives you an opportunity to confirm the migrated data before pulling in new cases from any active mailboxes:
    UPDATE Mailbox SET fEnabled = 0 WHERE fDeleted = 0;
  5. If this is a test instance, we recommend sanitizing the database to avoid interactions with your production instance.
  6. Start IIS on the FogBugz On Site web server, and allow the database to be automatically upgraded.
  7. Do the following from the FogBugz web server
    1. Make sure you are logged into FogBugz as an administrator
    2. Navigate to <your FogBugz URL>/f/debug/featureswitches
    3. Select the dropdown in the row labeled “SelfServiceSchemaFix” and choose “Force Enable” and click the “Update” button
    4. Navigate to <your FogBugz URL>/f/debug/database/schemacheck
    5. If there are errors on the page, click on the button labeled “Fix these errors”
    6. On the resulting page, click the “Back to Schema Check” button. If there are still errors on the page, contact us.
  8. If your version of FogBugz On Site is earlier than 8.18.5
    1. Run the SQL script we provided against the trial1 database (the trial number may be different if you have multiple On Site sites on the same server) to correct any schema errors.
    2. Verify <your FogBugz URL>/?pg=pgSchemaCheck has no errors when accessed from the FogBugz web server. If there are errors, contact us.
  9. Start ES backfills by navigating to <your FogBugz URL>/f/debug/es from the FogBugz web server (you’ll get 403s from external machines).  You may see an alert that says “Alias not found”.  If that’s the case, click the button below it that says “Create ES Alias”.
  10. Click the “Start Indexer Backfill” button for each document type (bug, wikipage, and discusstopic).
  11. Update the sURLEmailPrefix (if you are changing URLs):
    SELECT * FROM Setting WHERE sKey LIKE '%sURLPrefixEmail%';
    UPDATE Setting SET sValue = '<new URL including protocol>' WHERE sKey LIKE '%sURLPrefixEmail%';
  12. Disable the Kiln plugin:
    UPDATE Plugin SET fEnabled=0 WHERE sPluginId LIKE '%kiln%';
  13. Ensure there are no admin notifications under the Gear Menu
  14. Once you are satisfied with the migrated data, re-enable mailboxes as necessary (Gear Menu > Mailboxes)

Next Steps

Once your data is migrated to Manuscript On Premises, you may want to:

If you have any questions or would like assistance with this process, please don’t hesitate to contact us. We’re happy to help!