--- a/Sphinx/source/users/replication.rst	Wed Dec 14 10:09:44 2016 +0100
+++ b/Sphinx/source/users/replication.rst	Wed Dec 14 10:36:42 2016 +0100
@@ -17,9 +17,15 @@
 successive versions of Orthanc might use a different version of the
 database schema. If this happens, Orthanc will refuse to start (with
 an explicit message in its :ref:`logs <log>`), to let the user decides
-whether she actually wants to upgrade the database. At this point, the
-user might indeed decide to modify its :ref:`configuration file
-<configuration>` to create a new database elsewhere on the filesystem.
+whether she actually wants to upgrade the database.
+
+At this point, the user could indeed choose to modify its
+:ref:`configuration file <configuration>` in order to create a new
+database elsewhere on the filesystem (if using the default SQLite
+backend), or on the database management system (e.g. if using
+:ref:`PostgreSQL <postgresql>`). This is important to let the user
+experiment a new version of Orthanc, while keeping the older version
+up and running.
 
 If you decide to upgrade the database schema, you have to apply the
 following 3 steps:
@@ -31,32 +37,47 @@
    * Under Debian, use ``sudo /etc/init.d/orthanc stop``.
 
 2. Manually call Orthanc with the ``--upgrade`` command-line option, 
-   and point to your default configuration file:
+   and point to your configuration file:
 
-   * Under Microsoft Windows, ``Orthanc.exe c:/Orthanc/``.
+   * Under Microsoft Windows, ``Orthanc.exe c:/Orthanc/ --upgrade``.
    * Under Debian, use ``sudo /usr/sbin/Orthanc /etc/orthanc/ --upgrade``.
 
-3. Start the Orthanc service again:
+3. Once the upgrade process is over, restart the Orthanc service:
 
    * Under Microsoft Windows, use the `services control panel
      <https://en.wikipedia.org/wiki/Windows_service>`__.
-   * Under Debian, use ``sudo /etc/init.d/orthanc stop``.
+   * Under Debian, use ``sudo /etc/init.d/orthanc start``.
+
+**Important remarks:**
 
-Note that, depending on the size of the Orthanc database, upgrading
-the database schema might take time.
+* Orthanc is now considered as **stable**, which means that no upgrade
+  in the database schema should occur in the near future.
+* Depending on the size of the Orthanc database, upgrading the
+  database schema might take time, as this operation implies
+  re-reading all the DICOM instances from the disk.
+* In the case of the official Debian and Fedora packages, the default
+  location of the database changes with the version of its schema.
+  For instance, DB schema version 6 will be stored in
+  ``/var/lib/orthanc/db-v6/``. If upgrading the package (and if the
+  configuration files are purged), a new database will automatically
+  be created on the disk. Old data can be recovered either by changing
+  the configuration in ``/etc/orthanc/`` to point to the previous
+  location of the database then using ``--upgrade`` as written above,
+  or by using the instructions for replication below.
 
 
 Direct access to the filesystem
 -------------------------------
 
-The most direct way to replicate consists in using the
-`ImportDicomFiles
+The most direct way to replicate an instance of Orthanc consists in
+using the `ImportDicomFiles
 <https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/ImportDicomFiles/ImportDicomFiles.py>`_
 script of the Orthanc distribution. For instance, the following
-command would recursively explore the content of the ``OrthancStorage``
-folder (where Orthanc stores its DICOM files by default), and send
-each DICOM file inside this folder to the instance of Orthanc whose
-REST API is listening on ``http://192.168.0.2:8042``::
+command would recursively explore the content of the
+``OrthancStorage`` folder (where Orthanc stores its DICOM files by
+default), and send each DICOM file inside this folder to the instance
+of Orthanc whose REST API is listening on
+``http://192.168.0.2:8042``::
 
     $ python ImportDicomFiles.py 192.168.0.2 8042 OrthancStorage