Migrating JIRA to Another Server


This document describes how to migrate/upgrade to JIRA 6.4 on different server hardware or in a different server environment that entails one or more of the following:

  • a new operating system that will run JIRA,
  • new locations for storing your index and/or attachments, or
  • a new database or database system that will store JIRA's data.

If you are upgrading to a newer version of JIRA during the migration, please see Upgrading JIRA for information on the pre-requisite tasks you need to complete before upgrading.

On this page:

1. Before You Start

We strongly recommend performing your migration in a test environment first. Do not migrate your production JIRA server until you are satisfied that your test environment upgrade has been successful.

  • If you have any problems with your test environment which you cannot resolve, create an issue at our support site so that we can assist you.
  • If you have any problems during the migration of your production JIRA server, do not allow your users to start using this server. Instead:
    • Continue to use your old JIRA server — this will help ensure that you do not lose production data.
    • Also create an issue at our support site so that we can help you resolve the problems with your migration.

Some anti-virus or other Internet security tools may interfere with the migration and prevent the process from completing successfully. If you experience or anticipate experiencing such an issue with your anti-virus/Internet security tool, disable this tool first before proceeding with the JIRA migration.

2. Backing Up

2.1 Stop users from updating JIRA data

During the upgrade process, you'll export JIRA's database from your existing JIRA installation (via an XML backup) and then restore this backup into a new JIRA installation. To ensure that the data in the XML backup is consistent with the latest data in the system, you must temporarily restrict access to JIRA so users can't update the data. Refer to the Preventing users from accessing JIRA during backups page for more information.

(warning) Be aware! Inconsistent XML backups cannot be restored!

2.2 Back up your database

Perform an XML backup of your existing JIRA installation's external database. For large JIRA installations, this process may require several hours to complete.

The 'embedded database' is the HSQLDB database supplied with JIRA for evaluation purposes only. If you accidentally use the HSQLDB database in a production system, perform an XML backup of this database and continue on with this procedure.

2.3 Back up your JIRA Home directory

  1. Shut down JIRA.
  2. Locate the JIRA Home directory. You can find information about the location of the directory by navigating to the <jira-application-dir>/WEB-INF/classes/jira-application.properties file in your JIRA Installation Directory. Alternatively, you can open the JIRA Configuration Tool to see the directory that is set as your JIRA Home.
  3. Navigate to the directory specified in the configuration file and create a backup of it in another directory.
  4. (error) Delete the file <jira-home>/dbconfig.xml as soon as the backup is complete.

2.4 Back up your attachments and index directories if located outside your JIRA Home directory

If the attachments and index directories are located outside of your JIRA Home Directory, you must back them up separately. These pages describe how to find out where these directories are located in your implementation:

  • Your attachments directory — Refer to Configuring File Attachments page in the documentation for your version of JIRA.
  • Your index directory — Refer to Search Indexing page in the documentation for your version of JIRA.

Also refer to Backing Up Data for more information about backing up attachments in JIRA.

2.5 Back up your JIRA Installation directory

The 'JIRA Installation Directory' is the directory into which the JIRA application files and libraries were extracted when JIRA was installed.

3. Setting up your New JIRA Installation

If you are running a 'mission-critical' JIRA server, we highly recommend performing the remaining steps of this guide in a test environment (e.g. using a separate test JIRA database and a copy of your JIRA Home directory) before performing the upgrade for production use.

3.1 Install the new version of JIRA

First, you must start with a fresh installation of JIRA, either the current version or a newer one. If you are upgrading JIRA during this process, please see Upgrading JIRA for information on the pre-requisite tasks you need to complete before upgrading.

Download and extract the JIRA distribution you require, to a new directory. Do not overwrite your existing JIRA installation. Ensure this has been shut down and install the new JIRA version to a new location.

Follow the installation instructions for either:

(info) If you are using JIRA WAR, remember to build your new JIRA web application and deploy it to your server. For specific instructions, refer to the JIRA WAR installation page for your application server within the Installing JIRA WAR section.

3.2 Point your new JIRA to (a copy of) your existing JIRA Home directory

If your new JIRA 6.4 installation is on a new server, copy the backup of your existing JIRA Home Directory from the old server to the new server before proceeding.

To set up a "recommended" (not WAR) distribution:

  1. Open the JIRA Configuration Tool.
  2. Click the JIRA Home tab.
  3. Update the JIRA Home Directory field:
    • If your JIRA 6.4 installation is on a new server, update the JIRA Home Directory field to the path of your copied JIRA Home directory.
    • If your JIRA 6.4 installation is on the same server, update the JIRA Home Directory field to the path of your existing JIRA Home directory.
      (info) For more information about this directory, see JIRA Home Directory.

To set up a WAR distribution:

  1. Edit the jira-application.properties file located within the <jira-application-dir>/WEB-INF/classes subdirectory of your new JIRA 6.4 Installation Directory JIRA Installation Directory.
  2. Update the jira.home property in this file to the path of the new JIRA Home Directory:
    • If your JIRA 6.4 installation is on a new server, update the jira.home property to the path of your copied JIRA Home directory.
    • If your JIRA 6.4 installation is on the same server, update the jira.home property to the path of your existing JIRA Home directory.
      (info) For more information about this directory, see JIRA Home Directory.
  3. Remove the '#' at the beginning of the jira.home line (so that JIRA no longer regards this line as a comment).
  4. Save your updated jira-application.properties file.

(tick) You can also set your JIRA Home Directory's location by defining an operating system environment variable JIRA_HOME. This value of this variable takes precedence over the value of the jira.home property in the jira-application.properties file in your JIRA Installation Directory. See Setting your JIRA Home Directory for details.

3.3 Connect the new version of JIRA to a new, empty database

Create a new, empty database that your new JIRA installation will use to store its data.

Follow the appropriate 'Connecting JIRA to...' instructions for your database from stage 2, although from stage 4 of that procedure, be aware of the yellow note below:

If you are using a database (called jiradb, for example) with your existing JIRA installation and the database for your new JIRA installation is running on the same machine or database server, create your new database with a different name (e.g. something intuitive like jiradb_440 for JIRA 4.4.0). However, ensure the new database has identical access permissions to the old JIRA database. Consult your database administrator if you need assistance with this.

(info) You do not need to create a new database if you are using the embedded HSQL database.

3.4 Migrate your existing JIRA configurations over to your new JIRA installation

If you have modified properties in configuration files of your existing JIRA installation, make the same modifications in your new JIRA installation. However, because the properties in the configuration files may have changed between versions, you cannot simply copy the configuration files from your existing installation and replace the equivalent files in the new installation.

For each file you have modified in your existing JIRA installation, you need to manually edit each equivalent file in your new JIRA installation and re-apply your modifications. If a file is not present in your new JIRA installation (for example, osuser.xml in recent JIRA versions), then simply copy that file over to your new JIRA installation.

The table below lists the most commonly modified files and their locations within your JIRA Installation Directory:

File

Location in 'recommended' (formerly 'Standalone') JIRA distributions

Location in JIRA WAR

Description

jira-application.properties

atlassian-jira/WEB-INF/classes

webapp/WEB-INF/classes

Location of the JIRA Home Directory and Advanced JIRA Configuration in JIRA 4.3.x and earlier.

Any custom property values defined in the jira-application.properties file of your existing JIRA 4.3.x (or earlier) installation must be migrated across to the jira-application.properties file of your new JIRA 6.4 installation before you start your new JIRA installation.

Upon starting your new JIRA installation, any custom property values in the jira-application.properties file will automatically be migrated across to either the JIRA database or jira-config.properties file. jira.home is the only property of the jira-application.properties file subsequently used by JIRA.

setenv.bat (Windows) or setenv.sh (Linux)

bin

Application server's bin directory

Increasing JIRA Memory

osuser.xml
(not required if upgrading from JIRA 4.3.0 or later)

atlassian-jira/WEB-INF/classes

webapp/WEB-INF/classes

Modified if you have integrated LDAP with JIRA, integrated Crowd with JIRA, or if you are using a custom form of external user management or user authentication.

seraph-config.xml

atlassian-jira/WEB-INF/classes

webapp/WEB-INF/classes

Modified if you have integrated Crowd with JIRA.

server.xml

conf

Application server's conf directory

Modified in the following situations:

(tick) The version-specific upgrade notes contain details on properties which may have changed in these commonly modified files.

In addition to the files above, you should also consider and/or perform the following configurations as part of the upgrade process:

  • Using JIRA with Atlassian's Crowd? — If you are using Crowd with JIRA, configure your new JIRA to talk to Crowd as described in Integrating Crowd with JIRA.
  • Allocating additional memory to JIRA — If you had previously allocated additional memory to JIRA, do the same for your new JIRA instance. For more information refer to Increasing JIRA memory.
  • Plugins — For any plugins that you had installed in your old JIRA, download the plugin version for your new version of JIRA from the http://plugins.atlassian.com site.
  • Character encoding — Ensure that character encoding (i.e. locale) is the same on the new and old locations. Your new version of JIRA may not function correctly if attachments are moved between two system with incompatible encoding.
  • Customisations — If you had made any customisations (code, templates or configuration files), copy over compatible versions of these changes to the new JIRA. (The developers within your organisation who made the customisations to your old version will need to build and test equivalent changes for the new version, and provide you with the files to copy to your upgraded JIRA installation.)
  • (Optional) Running JIRA on a different port — If your new JIRA is installed on the same machine as your old JIRA, you may wish to make sure it runs on a different port (in case you ever need to restart your old JIRA). See Changing JIRA's TCP Ports for details.

3.5 Start your new version of JIRA

  1. Verify that your old JIRA installation is shut down — if this JIRA server is still operating, shut it down.
  2. If you installed the JIRA WAR distribution within Tomcat, delete the Tomcat work directory before restarting JIRA. If you do not do this, users may encounter errors when they try to display JIRA pages.
  3. Start up your new version of JIRA. For:
    • 'Recommended' distributions — follow the Starting JIRA instructions.
    • WAR distributions — follow the instructions for starting JIRA for your application server within the Installing JIRA WAR section.
      (info) During the startup process, your new JIRA installation will create any required database indexes. If you created any custom database indexes, please check them afterwards and remove any that duplicate the indexes added by JIRA.

Do not restart your old JIRA installation...

If your new JIRA 6.4 installation is on the same server as your old one, it may still be configured to use the same JIRA Home directory as your new JIRA installation. Running two separate JIRA installations which share a common JIRA Home directory can lead to serious data corruption.

Nevertheless, we recommend that you do not delete any aspect (or backed up component) of your old JIRA installation, until you are satisfied that your upgraded JIRA installation is functioning as expected.

3.6 Import your old JIRA data into your new JIRA

After you have started your new JIRA installation, import the data from your old instance into the new instance. You will need the backup file of data from your old JIRA that you created earlier in these instructions (above).

To import your old JIRA data into your new JIRA:

  1. Log in as a user with the 'JIRA System Administrators' global permission.
  2. Select Administration > System > Import & Export > Restore System (tab) to open the 'Restore JIRA data from Backup' page.
    (tick) Keyboard shortcut: 'g' + 'g' + type 'rest'
  3. In the File name field, specify the XML backup file you created previously during the export process (above). That zipped file should contain two xml files: activeobjects.xml and entities.xml. Both of these files must be included in the zipped file for the import process to work.
  4. Restore the attachments directory that you backed up previously, into the attachments directory of your new JIRA. (See Restoring Data.)
    (info) Avoid passing through a proxy when performing an XML restore, especially if your JIRA instance is very large. Using a proxy may cause timeout errors.
  5. Access JIRA via your web browser again and log in using a username from your previous JIRA installation.
  6. Take a quick look around your JIRA site to confirm that your projects and issues are present and everything looks normal. You should see the new JIRA version number in the page footer.

4. Post Migration Checks and Tasks

It is strongly recommended that you perform the following checks and tasks after you have started your new instance of JIRA:

  1. Check your server logs for error messages, even if JIRA appears to be running correctly. If there are any errors there that you cannot resolve, create a support case in https://support.atlassian.com, attach your log file and we will advise you on the errors.
  2. If you were previously using External User Management, enable it in the new JIRA instance.
  3. If you changed machines when upgrading, change the paths to the indexes, attachments and backup directories, from within the Administration section of JIRA.
  4. Enable email, if you disabled it during testing.
  5. If you migrated any customisations from your old JIRA to the new JIRA, ensure that they are tested thoroughly.
    1. If you had downloaded plugins for the new version of JIRA, install the downloaded JAR file(s) in your new JIRA version and carry out any other required installation for the plugin.
    2. If the plugin has a properties file, apply the same changes to it as you had in the old properties file (don't just copy over the old properties file).
  6. Once you have confirmed that the new server is working correctly, ensure that the production license is updated for the new server ID, as follows:
    1. Log in to https://my.atlassian.com.
    2. Locate the appropriate license.
    3. Edit the Server ID, as per the new production Server ID, and save it.
    4. Update the production license in the new server.

Congratulations! You have completed your JIRA migration/upgrade.

See Also

Disabling Auto-Export
Restoring Data
Upgrading JIRA
Switching Application Servers to Apache Tomcat
Switching Databases

Was this helpful?

Thanks for your feedback!

39 Archived comments

  1. User avatar

    Anonymous

    Messages from installation:

    ....

    Where should JIRA 5.0.3 be installed?
    [/opt/atlassian/jira]
    /opt/atlassian/domyseo
    It appears that JIRA is already installed in the directory you selected. Please choose a different directory.

    Where should JIRA 5.0.3 be installed?
    [/opt/atlassian/domyseo]

    What does it mean "3.2 Point your new JIRA to (a copy of) your existing JIRA Home directory"?!

    Somebody needs to review the instructions.

    05 May 2012
    1. User avatar

      Giles Gaskell

      Hi there,

      Could I ask what you're using these instructions for?

      As mentioned at the top of this page, the instructions on this page are designed to cover the following two scenarios:

      1. upgrading to JIRA 5.0.3 (or other 5.0.x version) from a version prior to 4.0.0 (on the same server hardware/environment - which I've just clarified above)
        (info) This would entail having to upgrade to JIRA 4.4.x — preferably JIRA 4.4.5 first using the procedure on this page. However, to then upgrade from JIRA 4.4.5 to 5.0.x (i.e. the 2nd step of the upgrade process), you can use the regular Upgrading JIRA procedure instead.
        OR
      2. migrating/upgrading to JIRA 5.0.3 (or other 5.0.x version) on different server hardware or in a different server environment, which entails one or more of the following:
        • a new operating system that will run JIRA,
        • new locations for storing your index and/or attachments, or
        • a new database or database system that will store JIRA's data.
        ?

      If neither of the two scenarios above matches your situation, then these instructions are not for you. Hence, if you can describe your scenario, I could point you to the relevant page.

      In answer to your question:

      What does it mean "3.2 Point your new JIRA to (a copy of) your existing JIRA Home directory"?!

      The brackets around '(a copy of)' indicates that this part of the statement is an option. As mentioned immediately below this heading in the documentation above:

      If your new JIRA 5.0.x installation is on a new server, copy your existing JIRA Home Directory from the old server to the new server before proceeding.

      That means if you're following the instructions on this page to accomplish scenario 2 (above), then you should copy your existing JIRA Home Directory from your old server environment to your new server environment. ('Pointing' in this context means getting your new/upgraded JIRA installation to recognise where its JIRA Home Directory is located.)

      Hope this clarifies things. If not, please let me know, so that we can improve the content above.

      Cheers,

      Giles.

      07 May 2012
  2. User avatar

    Anonymous

    I'm confused. At the top it states:

    Please Note: This is a two-step process. You will need to use this procedure to upgrade to JIRA 4.4.x first before you can upgrade to JIRA 5.0.x.

    But then in 3. Setting up your New JIRA Installation you proceed with instructions on setting up Jira 5. I would expect to see 4.4.x instructions there.

    15 May 2012
    1. User avatar

      Giles Gaskell

      Hi there,

      Thanks for pointing out the discrepancy above, which has now been corrected and is hopefully clearer.

      Cheers,

      Giles.

      P.S. Apart from references to explicit JIRA version numbers, there is very little difference between the 'Migrating JIRA to Another Server' guide on this page and the equivalent guide for JIRA 4.4.x.

      16 May 2012
  3. User avatar

    Anonymous

    When I import old JIRA data into new JIRA, the following error was returned. Where did it go wrong?

    Unexpected error occurred during import: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:TrustedApplication][name,http://***.com:8005/][timeout,2000] (SQL Exception while executing the following:INSERT INTO trustedapp (ID, APPLICATION_ID, NAME, PUBLIC_KEY, IP_MATCH, URL_MATCH, TIMEOUT, CREATED, CREATED_BY, UPDATED, UPDATED_BY) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (Column 'ID' cannot be null))

    12 Jul 2012
  4. User avatar

    Anonymous

    Hi.  Quite some time ago inadvertently had to follow these (older version at the time - maybe 4.3?) instructions as my old host machine crashed.  Had a daily backup so lost very little which was good. Instructions helped - thanks!

    Not a biggy, but just noticed that in the activity stream where I would expect avatar am getting reference to old server.  as in [code] "machine: port/secure/ViewProfile.jspa?name=reporter" [code]  Any idea where this is configured?  I cannot see this anywhere?

     

    07 Aug 2012
  5. User avatar

    Anonymous

    Hi, we also want to upgrade from 3.13 to version 5. In version 3.13 is no entry about the home directory within the jira-application.properties configuration file. What should i backup instead of?

    Thanks a lot for response.

     

    23 Aug 2012
    1. User avatar

      Anonymous

      In the beginning of this page it says you first have to update to 4.4.x.

      Look for the orange exclamation mark triangle close to the top of this page.

      25 Aug 2012
      1. User avatar

        Anonymous

        Hi and thank you for answering. I have read this part of the text and also the followeing documentation: 'Migrating JIRA to Another Server' guide (in the JIRA 4.4.x documentation)

        But in this, there is also the speech of "Backing up your Home Directory".

        27 Aug 2012
  6. User avatar

    Anonymous

    hi after importing the projects i cant see the old attachment link in the issues which is created in before.

    03 Sep 2012
    1. User avatar

      Anonymous

      hi! have you resolved your problem? can we know how?

      14 Jan 2013
  7. User avatar

    Anonymous

    hi can i know what is the default database of JIRA after installation?

    14 Jan 2013
  8. User avatar

    Louis Halfen

    Is it possible to incorporate 3.13 data in a brand new 5.2 JIRA version without passing all 4.xx steps ?

    01 Feb 2013
  9. User avatar

    Anonymous

    Hello All

    We are planning to install JIRA in the local system for test drive .  After completion of installation in the local system,  Then we want to install the JIRA in Git Server, Which is an internal server linux  OS . can we use the same key  for the installation process  in Git server. OR can we add the new server ID to Generate the Key.

    05 Feb 2013
  10. User avatar

    Rumesh Bandara

    I would say Atlassian's documentations are bit messy. You are mixing all the details everywhere and there are so many links to other pages in a one doc. This is not required since it'll be confusing to proceed with reading...

    05 Mar 2013
  11. User avatar

    Bullseye Digital

    We are not impressed by your Documentation nor the complexity of simple tasks.

    16 Mar 2013
  12. User avatar

    Gerry Tan

    Hi, I'm a bit concerned about "copying old home dir into new server and switching into it". Does that mean after the migration process is finished I have to keep and maintain two home dirs?

    21 Mar 2013
    1. User avatar

      Boris Berenberg [Atlassian]

      Yes and no. You will have to maintain 1 home directory on your production environment, and 1 on your staging environment. What is really means is that once you have set up JIRA on a separate server, and have copied over you old home directory, you need to make sure to update your JIRA configuration to let it know where the home directory resides (assuming the location has changed between production and staging).

      22 Mar 2013
  13. User avatar

    Omar Shehab

    Remove the '#' at the beginning of this line (so that JIRA no longer regards this line as a comment).

    What line are you talking about?

    13 Jun 2013
    1. User avatar

      Boris Berenberg [Atlassian]

      The jira.home line. I have updated the docs to clarify this. Thanks for your feedback.

      13 Jun 2013
      1. User avatar

        Omar Shehab

        Thanks!

        13 Jun 2013
  14. User avatar

    Anonymous

    I installed new server and moved old JIRA home folder to /var/atlassian/application-data/jira-old and edited jira-application.properties to point it to jira-old location. After starting JIRA , it did not even ask me if I want to use database or not. It restored everything from my old JIRA. Created tables, Attachments and everything, so in this case do I still need to restore old mysql dump or any other backup to new server or not? And can I delete  /var/atlassian/application-data/JIRA folder since I don't use it anymore.

    25 Oct 2013
  15. User avatar

    Anonymous

    Is it possible to migrate to another server when the license has no support or updates?

    05 Nov 2013
  16. User avatar

    Anonymous

    Hello,

    It could be done the migration from JIRA 6.0.1 to JIRA ON DEMAND without losing any information???

    13 Nov 2013
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Hi,

      You can import from JIRA 6.0.1 into JIRA OnDemand without losing data. See these instructions. If you run into problems, please contact support for help.

      Kind Regards,
      Andrew

      13 Nov 2013
  17. User avatar

    Eddom Lim

    Hi,

     

    I must renew the support license in order to do migration to another new server?

     

    Regards,

    Eddom

    02 Dec 2013
  18. User avatar

    Luis Hdez

    Sorry but this is an awful migration system

    24 Mar 2014
  19. User avatar

    W H

    Have to agree with the above...the recommended backup strategy is "use the native backup tools of your database product," but having done that, why would my migration path not contain any of those steps?  Because if that is the best way to backup, why not use it to migrate as well?

    I.E. I would think migration to a new server would contain the same directions as this article, since it pretty much is the same thing minus the license changing: Establishing Staging Server Environments for JIRA

    One of the most frustrating things about Atlassian products is the documentation, and the application server it is running on seems to have capacity issues mid-afternoon US Eastern time.  That and the configuration between products is different when trying to complete the same steps.  If there is a QA team at Atlassian, they aren't being listened to or aren't doing their jobs....

    27 Mar 2014
  20. User avatar

    Scaled Atlssian Tools Support

    In step 2.3.4 you say "(error) Delete the file <jira-home>/dbconfig.xml as soon as the backup is complete."

    I assume you mean to do this on the copy and not the original?  Might be good to clarify this.

    18 Jun 2014
  21. User avatar

    Oleg _

    Hello,

    I am considering using his method for creating a staging environment.

    How do I make sure that production license stays with the production server and does not migrate to the staging instance?

    Thank you

    24 Aug 2014
  22. User avatar

    Michael Schwager

    In Section 3.3, you instruct users to "Connect the new version of JIRA to a new, empty database", which I did (Mysql) following the instructions in the link. I can see the database via the mysql command. But it is empty!

    That means that, 3.4 and 3.5 will work just fine but in section 3.6 I get an HTTP 500 error which makes perfect sense to me. It complains:

    This is not a permissions problem- think about it. If the database is empty, how is it going to see any tables whatsoever? Indeed, at the shell prompt I see:

    Can you tell us what to do in Section 3.6?  This is for version 6.3.15 of JIRA on Centos Linux 7.

     

    19 Feb 2015
    1. User avatar

      Blake Atkinson

      What does "show grants" return for this mysql user? The "jirauser" will create the tables necessary.

      19 Feb 2015
      1. User avatar

        Michael Schwager

        19 Feb 2015
    1. User avatar

      Michael Schwager

      I spoke to Support, and they told me my steps were correct up till this point. Still, there was a line in the dbconfig.xml file with <schema>PUBLIC</schema> in it... even though I'd chosen MySQL as the backend db, apparently this is a Postgres thing.

      I deleted the line per their request and now I have gotten to the "Import Existing Data" page on the Web. We'll see how it goes...

      20 Feb 2015
      1. User avatar

        Michael Schwager

        That did the trick. My database import completed successfully.

        20 Feb 2015
  23. User avatar

    Manuel Borja

    I think an important step is missing. If you are using a temporary server to simulate final migration, after you copy and set the new JIRA home by using the configuration tool, you should also set the temporary database by using the same tool, otherwise you can impact your current production database.

    23 Jun 2015
    1. User avatar

      W H

      It's kind of hidden, but it is in the backup section...Under 2.3, number 4 says Delete the file <jira-home>/dbconfig.xml as soon as the backup is complete.

      That would take care of connecting to the database, until you added the connection information again.

      But really this should be prevented from isolation, which you should be doing between production and test environments.  It can't impact a database it can't talk to.  (wink)

      23 Jun 2015
  24. User avatar

    Manuel Borja

    I hope everybody will do what they "should" do.

    23 Jun 2015
  25. User avatar

    Robert Droppleman

    If I'm only migrating JIRA to a new OS while keeping the DB the same, do I still need to create a new DB as in step 3.3?

    26 Jun 2015
Powered by Confluence and Scroll Viewport