This document describes the procedure for upgrading to the latest version of Confluence on Windows or Linux.

Before you start

Check your Confluence licence is valid.To check go to > General Configuration > Atlassian Support Tools > Health Check and make sure the license support period has not expired. If your support period has expired renew your licence and reapply it before proceeding with the upgrade.

Make a note of any modifications to your Confluence instance (for example layouts or a custom theme).Any customisation you wish to maintain will need to be reapplied after upgrading.

Step 1 Determine your upgrade path and method

Find the upgrade path that works for your current version of Confluence and the version you plan to upgrade to.

The following table will help you to determine the most efficient upgrade path from your current version to the latest versions of Confluence. To use the table find your current installed version of Confluence in the left column and follow the suggested path.

Follow the steps below to perform the upgrade on your cloned environment.

Test all your unsupported add-ons (plugins) and any customisation (for example custom themes and layouts) with the new version before proceeding with the upgrade in your production environment.

Step 3 Back up

Before you begin the Confluence upgrade you must back up:

your external databaseYou must perform a manual backup of your external database and confirm that the backup was created properly. If you are unfamiliar with the backup-restore facilities of your database, you can simply restore the backup to a different system to ensure the backup worked before proceeding.

your Confluence Home directoryThe Confluence Home directory is the folder where Confluence stores its configuration information, search indexes and page attachments. The location of the Home directory is stored in a configuration file called confluence-init.properties, which is located inside the confluence/WEB-INF/classes directory in your Confluence Installation directory.if you store attachments outside the Confluence Home directory, you should also backup your attachments directory.

the Confluence installation directoryThis is where the Confluence application files and libraries were unpacked (unzipped) when Confluence was originally installed.

The installation wizard will back up your Confluence directories as part of the installation process, but you should also back these directions up manually before starting the upgrade.

Step 4 Upgrade Confluence in your production environment

Windows Users: run the .exe file.If prompted to allow the upgrade wizard to make changes to your computer, choose 'Yes'. If you do not, the installation wizard will have restricted access to your operating system and any subsequent installation options will be limited.

Linux users: open a Linux console and change directory (cd) to the '.bin' file directory and execute the '.bin' file. If the '.bin' file is not executable after downloading it, make it executable, for example chmod a+x atlassian-confluence-5.6.1-x64.bin (specify the exact filename of the installer you downloaded).

The installation wizard will guide you through the upgrade process. Some things to note:

Verify that the Existing Confluence installation directory suggested by the wizard is correct. This is especially important if you have multiple Confluence installations running on the same machine.

At the 'Back up Confluence directories' step, ensure 'Back up Confluence home' is selected. This will create a .zip backup of the Confluence home and installation directories. This is strongly recommended.

The installation wizard will notify you of customisations in the Confluence Installation directory. Make a note of these before proceeding as you will need to manually reapply these customisations after the upgrade is complete.

If you have not already done so, the wizard will prompt you to backup your external database and check plugin compatibility. If your database does not support online backups you will need to stop the installation wizard at this point.

The wizard will shut down your Confluence instance and proceed with the upgrade. Once complete, it will restart Confluence and you can then launch Confluence in your browser to confirm the upgrade was successful.

During the upgrade the wizard will migrate following from your existing Confluence installation:

If you are using an Oracle or MySQL database, you'll need to copy the jdbc driver jar file from your existing Confluence installation directory to confluence/WEB-INF/lib in your new installation directory.

Other configurations or customisations (including any other modifications in the server.xml file) are not migrated during the upgrade and need to be reapplied manually. See below for more information.

Additional steps when customisations are present

The installation wizard's ability to notify you about customisations will depend on how your existing Confluence instance was installed:

If your current Confluence instance was installed using the installer, the wizard will check the entire Confluence Installation directory.

If your current Confluence instance was installed manually it will only check the confluence subdirectory of the Confluence Installation directory. The installation wizard will not notify you of modifications in any other directory, for example modifications to start-up scripts under the bin directory or modifications to the server.xml file (such as an SSL configuration).

If customisations are present you will need to perform the following steps after the upgrade is complete:

Stop the upgraded Confluence instance.

Reapply the customisations to the relevant files in the upgraded Confluence Installation directory.

Restart the upgraded Confluence instance.

We strongly recommend you test your customisations in a test instance prior to upgrading your production instance as changes may have been made to Confluence that make your customisations unsuable.

Troubleshooting

Did something go wrong?

If you need to retry the upgrade, you must restore your pre-upgrade backups first. Do not attempt to run an upgrade again, or start the older version of Confluence again after an upgrade has failed.

Some common issues encountered while upgrading:

Cannot proceed with upgrade because license has expired If your licence has expired and was not renewed and reapplied before upgrading you will receive errors during the upgrade process. See upgrading beyond current license period for information on how to resolve this problem.

Unable to proceed with upgrade because of a conflict with anti virusSome anti-virus or other Internet security tools may interfere with the Confluence upgrade process and prevent the process from completing successfully, particularly if you run Confluence as a Windows service. If you experience or anticipate experiencing such an issue with your anti-virus / Internet security tool, disable this tool first before proceeding with the Confluence upgrade.

Database does not support online backupsThe upgrade wizard will prompt you to backup your database using your database's backup utilities. If your database does not support online backups, stop the upgrade process, shut down Confluence, perform your database backup and then run the installer again to continue with the upgrade.

Upgrade is taking a very long timeIf you have a very large database (i.e. database backups take a very long time to complete), setting the confluence.upgrade.recovery.file.enabledsystem property to false will speed up the upgrade process. It should be used only when there is a process to back up database and verify the backup before performing an upgrade.

139 Comments

Anonymous

I don't want to rant, but what's the point of a semi automatic updater?

E.g. this:

TCP port values in your existing Confluence installation's server.xml file. Be aware that other configurations or customisations in this file are not migrated during upgrade, and will need to be re-applied.

If I have to migrate other settings manually (which I think a lot of us will have to), I might as well adjust the port as well because I have to edit the file anyway. Chances are, I'll just replace the whole tag if other changes were made as well (IP bind for example).

It's nice Confluence detects, what was changed/deleted/what ever but if it can detect the changes, why not go one more step and migrate them as well?

An automatic upgrade would be an excellent feature which'd save a lot of time. But as it is now, it seems pretty useless to me. I just have a hard time believing that this upgrade function does the trick for anyone who uses Confluence for professional purposes.

I understand the frustration with not handling the customisations of server.xml . It is actually technically very challenging to come up with a good solution to the problem. Here are the reasons for the approach we have taken:

the format of the tomcat's server.xml may change from version to version therefore we cannot just copy the old one

there can be a huge variety of customisations to the server.xml and we cannot cover all those changes and carry them over. E.g. customers can add new connectors for ssl, mod_proxy, mod_jk and many other or they can add jndi resources or change the parameters of any of the tags. We simply cannot cover everything.

It is possible that customisations in server.xml depend on external files that don't get copied during migration (e.g. ssl certificate file if he lives inside the installation directory.

There is a discussion for the approach we took in this issue (it's JIRA's issue, but we take the same approach as in confluence.

Anonymous

The handling of the system user / file system permissions of the upgrade tool is not exactly what i'd expect - and far from best practice on Linux.

While Jira seems to completely ignore permissions and just runs tomcat as root, Confluence did start tomcat with a (random?) uid 1506.

The installer also changed all relevant files to be owned uid 1506.

If you actually make use of a non-privileged user (which is a good thing in general and IMO quite mandatory when running things in production) - why not allow the administrator to specify the uid at least?

Choosing a random UID and chowning files (also making them world-readable, etc) is unnecessary.

Aside from that the upgrade went fine - I just had to adjust the usual tomcat config (port, AJP connector, disable http, ..) and the filesystem permissions in some places and some modifications in the start scripts.

Anonymous

I know this is an old thread, but would it be possible to give us the choice of whether to start Confluence or not when upgrading using the scripts? The upgrade is quite useful but I have my memory settings in setenv.sh and when these are removed Confluence can crash with an out of memory error when undertaking the first start upgrade process.

While I'm at it, I'd also like the ability to automatically restore files that were "Added" as well.

Hi, thanks for your feedback. There is an improvement opened for the behavior you are describing:
CONF-24414
-
On upgrade if we found there are modz in the system we cannot handle we should give the customer an option not to start confluenceOpen
; please vote for it. The memory settings will be migrated during the upgrade. If it is not the case can you please raise an issue for that (please attach your setenv.sh script).

Thanks for that Anatoli, much appreciated. It looks like settings in JAVA_OPTS are kept during an upgrade, but settings in CATALINA_OPTS are not (which is only used when running Tomcat, not when shutting down Tomcat). A temporary work around is to move your CATALINA_OPTS to JAVA_OPTS after stopping Confluence but before upgrading.

Anonymous

For those of running Confluence or JIRA on Windows, I created a script that backs up and restores the customizations. Even if you determine that they can't directly be restored in your environment and would need to be merged, it at least makes the backup part easy (without having to back up all the other files):

Anonymous

I get the error "Unable to determine location of the home directory. 'confluence.home' was not found inside confluence-init.properties.".

What exactly means it? My confluence.home is defined in this file as "confluence.home=/volume1/@atlassian/application-data/confluence".

When I remove the definition of confluence.home, I get the error "An error occurred when parsing your installation directory. Unfortunately the installer will be unable to continue with the automated upgrade".

During the upgrade the upgrader expects to find a location of the home directory defined as

confluence.home=/path/to/confluence/home

in the <INSTALLATION-DIR>/confluence/WEB-INF/classes/confluence-init.properties . It needs it to make the backup of the home directory. If it cannot find it it shows the error that you see. It seems like in your case the behavior is not what it is supposed to be (you might be hitting a bug?). Can you please raise a support issue and we will help you to find out what is happening. Please attach your original confluence-init.properties files to the issue you create (we will try to reproduce the problem locally.

Anonymous

It appears that at least in 3.5.x versions the confluence runs perfectly fine when had -Dconfluence.home set (startup parameter) with not properly set confluence.home in <INSTALLATION-DIR>/confluence/WEB-INF/classes/confluence-init.properties file.

Yet the installer looks into confluence-init.properties and that causes an error.

After setting proper confluence.home in confluence-init.properties the installer works.

I just performed an upgrade of my Confluence 3.5.9 to 4.0 on my Windows Server 2008 64-bit Standard using SQL Server 2008 R2. I had my Confluence/Tomcat configured to start as a Windows service. At the end of the install, the DOS-box looking Tomcat window appeared in order to start Tomcat rather than it being started by the service. Not a big deal, as it may be hard for your installer to know I have it setup as a service.It would be nice to add a note in your installation instructions that the Tomcat window will start, and then what to do if you normally use it as a service.

More concerning to me though is that in the Tomcat window it showed a bunch of messages with "WARNING" and I have no idea if those matter (knowing nothing about Tomcat as I do). Things like:

Thanks for your feedback. You can safely ignore the warning you mentioned it is harmless.

As for the service not being automatically detected - you are right it is just difficult for us to figure it out when we do the upgrade. The experience is much smoother for users who would install 4.0 and then upgrade forward to 4.0.x(and later versions). During the installation we ask if you want to install confluence as a service and when we upgrade we honor the original decision and start confluence accordingly. Unfortunately in your case (i.e. when upgrading from pre 4.0 versions) you will have the non-ideal behavior even when upgrading forward. On a plus side the old service should still work as it points to the file that now starts the newer version.

Thanks for your comment, we should warn people who use oracle that on upgrade they need to copy over the drivers to the new installation.

Unfortunately Oracle is a special case because we don't bundle Oracle drivers that's why they are not in WEB-INF/lib. During the upgrade we don't move over any added files to the new installation and in case of oracle it would mean that confluence wouldn't be able to connect to a db.

We try to warn people in general case by showing the list the customisations ( we mention it in the documentation - step 5 b) and ask to move them manually.

I performed the 3.5.5 -> 4 upgrade on a staging server and it worked fine. However, the installation directory is named the same as before, which is 'confluence-3.5.5-std'. Is it possible to safely rename that directory after the fact to something like 'confluence-4-std', or maybe even 'confluence-std'?

Note: I'm running it on Windows 2008 as a service, and I know I would need to uninstall/reinstall that part of it. I'm mostly worried about Confluence having that path stored somewhere in its configuration.

Yes it is possible to safely rename the directory as long as you change everything that points to it to point to the new directory. As you mentioned - service is probably the most important but you might also have menu items or shortcuts. It is a good idea to make a name without a version so that the next time you upgrade you don't have to go through the renaming again.

Some background on why installer doesn't change the name automatically:

On one hand if the old directory has the version number in its name then upgrading on-top will mean the new version will sit in the directory named after an old version. On the other hand customers may have existing scripts, services, custom created menu shortcuts on windows or other environment settings that depend on the existing name of the directory. At the end we decided that preserving the environment and not breaking the existing scripts is more important and we went with the on-top upgrade option. We have also changed the suggested installation directory name for the installer - now it doesn't include a version number.

This is a bit confusing. I first was in the believe the installer/upgrader was still searching for other paths. After the process was idle for some time, i decided to enter the installation path, and the upgrade process continued. Might be an idea to prompt the user (by example: "Is this path correct? Hit enter to use the path specified or enter another path") in future versions.

Thanks for your feedback and suggestions. The progress indicator for the command line installer is definitely a good idea, it will make the process easier to follow. The indicator will probably solve the initial confusion too (with the directory location) - it will be clear that unless the process shows it is in progress then it is waiting for user input.

Anonymous

Hi

Environment: linux, confluence 3.5.3, Oracle as backend data base

We do nightly backups to XML. To test 4.0, we did the normal manualunpack and restored from XML backup to a clean database and cleanconfluence_home. Other than a few minor hiccoughs, this seems to beworking well.

However, the notes above mention that this is not the recommendedaproach. Is there a particular reason?

Anonymous

I'm doing some studies due to a soon-to-be rollout of confluence (if things like upgrading and migration goes well...) We will use Linux/Postgres in production environment, but for evaluation purposes I'm on Win32.

When upgrading from 3.5.13-evaluation (standalone) to 4.0.5-x32 (standalone) the installer quits with error dialog box showing something similar to "Not a valid directory". There's no way to continue from here.

I have one 4.0.5-x32 installation in C:\Confluence (and C:Confluence-Data) and now I was testing upgrading from 3.2 to 4.0.5 in a separate catalog C:\ConfluenceTest (yes, via subsequent upgrades to 3.3, 3.4 and 3.5 respectively - this hurts...). And the final upgrade from 3.5 to 4 failed.

The directory you have selected is not a valid Confluence installation directory.

This message is shown when the upgrader cannot recognize the structure of the installation directory. In particular we are looking for confluence subdirectory inside the installation directory and if we cannot find it we show this message. In your case the upgrader expects to see C:\ConfluenceTest\confluence .

You can always fall back use the manual upgrade method to upgrade from 3.5 to 4.0 (the same steps as you used to upgrade from 3.4 to 3.5).

You might want to contact support - they will help you with the upgrade.

This is just my personal experience, if you are using Linux and have an experienced admin then use the tar.gz manual install instead. In Unix/Linux most good software is built independent of the OS.

An experienced Unix admin will be able to setup a non-privileged user, some symbolic links and make Confluence pretty much independent of the OS with alot more flexibility in the future.

For example, to upgrade from Confluence 3.5.5 to 4.1, I spent 20 minutes to read about the slight differences and quickly performed the upgrade in Staging. After that moving to say Production would simply be a matter of TARing the Confluence directory in IST and unTARing it to Production, launch Confluence and update the plugins.

Thanks for your input guys. There is a bit of a discussion happened on JIRA's page about the upgrader overwriting the existing dir Re: Upgrading JIRA . Feel free to comment there as both confluence and JIRA installers work the same way.

I have manually upgraded my test environment from 3.4.2, to 3.5, to 3.5.13, to 4.0 over the course of a few days. In my production environment, is it possible to upgrade from 3.4.2 to 4.0 (manually)? This will save me much time ...

I know this is generally a 'no-brainer' in IT circles, but there should probably be a note in the install instructions or a check-list item in the installer that anti-virus programs must be paused or disabled during installation when using the installer. Kapersky thinks the installer is trying to establish remote control, and terminates the process and quarantines the file.

Anonymous

Just successfully performed an upgrade from 3.5.5 -> 4.1.2 using the guided install, although not without some hiccups.

We use MS SQL, and our standard server config has the "no count" option enabled. As you know, all Atlassian apps require "no count" to be disabled; and as this is a global server-wide setting, we use a customised version of the open source jTDS driver to which we've added the ability to disable the no count option on a per connection basis.

The problem is that after the guided install wipes the Confluence install directory and installs the new version (which includes a bundled jTDS driver, sans this customisation); it immediately starts Confluence and proceeds with the upgrade routine. The db schema changes applied as part of this upgrade process ultimately fail (presumably due to the "no count" option being enabled). To resolve, I had to shutdown Confluence, restore the database and home directories to their pre-upgrade state, copy over our customised jTDS driver, and restart Confluence (which re-ran the db schema upgrade process; this time successfully).

I realise that the guided install is intended for vanilla environments, but I think it would be useful to provide a checkpoint (ie. user prompt) after the installation files have been copied, and before Confluence is started (eg. "Start new Confluence? [y, enter]). This would provide an opportunity for any customised files (already identified by the installer) to be copied/modified before the upgrade continues.

Anonymous

I have installed/upgraded using the Standalone version for a few years now. What is the difference between the Standalone version and the Windows Installer version from an installation stand point? I am currently using version 3.5.9. For my next upgrade, can I use the Windows Installer version to make the installation easier for myself?

The installer takes care of most manual steps that you otherwise would have to perform. E.g. when installing it sets the location of home directory in the right file, it is distributed with jre so you don't have to download/install it, it lets you change port numbers, it automatically creates windows service if you ask it to.

The same executable can also be used for upgrade and it will backup all relevant directories, extract the new files will check if you have customised things and will let you know if you have to re-apply customisations manually.

Anonymous

We are currently running confluence 3.3 with very little customisation other than LDAP integration and HTTPS implementation.

We are looking to upgrade to the latest version of Confluence but also move it to another server. Would it be possible to do an export of the 3.3 data then import to a clean install of Confluence 4.1.x?

We are also looking at doing the same with JIRA, moving from 4.1.2 to 4.4.x.

Depending on the size of your Confluence you might be able to perform upgrade exporting the data from 3.3 and then importing to 4.1.x. Keep in mind that only data will be preserved but not some of the settings or installed plugins.

If you have a larger instance we generally recommend following manual steps (where you backup db and home directory manually and then configure the new version against the old home dir and pointing to the old db). The same applies to JIRA upgrade.

Anonymous

I attempted an upgrade from 4.0 -> 4.1.0.3. Should be a slam dunk right? Instead it says I have a customization to some file no one has ever touched. Then it cannot delete the home directory and so I have to ignore that to continue. Then it just fails to be able to delete some other file.

I mean you've gotta be kidding me. Please get your documentation straight so I don't have to waste my time like this. Thank goodness I use VMWare and took a snapshot of this thing so I don't have to piece it back together with your confusing documentation.

Oh, and I second the comment above about a semi-automatic installer. You might as well just tell us to use Beyond Compare or something and upgrade it that way so I can line by line choose to keep customizations where needed. The installer may be doing more harm than good here.

Do you need us to run the installer as admin or something? Is that why I got the error about not being able to delete the old home directory??

If you are on windows the most possible cause of 'it cannot delete the home directory' problem would be the fact that some other process has a file opened (or you simply view the directory in explorer). Windows does not allow the deletion if some other process holds on to a file descriptor.

Do you need us to run the installer as admin or something?

We do recommend running with admin privileges but it is not necessary if you installed it previously as normal user. In any case it would tell you that you need to run as admin if it finds that it needs admin preventives.

Anonymous

Hi Anatoli,

What is the difference between "One-Click Evaluation Installer" and "Windows Installer". When I worked on "One-Click Evaluation Installer" the Home Directory has its own path unlike the "Windows Installer" which is asking us to give the path for Home Directory...

The old "One-click Evaluation Installer" was something aimed to evaluators were you could just run it, see how confluence works and then if you wanted to install confluence properly you had to go through a long manual process. The "Windows Installer" (and *nix installer for that matter) adds a lot of functionality - proper installation/ support for upgrades/ support for Windows/Unix services/ validation that necessary ports are available and many other features. It also simplifies the process as you are no longer required to pre install JRE.

You can still use the installer to quickly evaluate Confluence. It has 'use suggested defaults' option which makes it a 'one-click' experience.

As per my requirement I need to install "3.4.9 - One-Click Evaluation Installer (EXE)" in my environment. But I have encountered with few problems like, I am not able set the Home Directory's path according to my requirement. Can you please provide the procedure or link for the proper installation of the conflu 3.4.9.

Anonymous

The installer will handle both situation. If the instance is still running it will warn you that the instance will be stopped, wait for you to confirm and then will proceed with the upgrade. If it is stopped it will go ahead with the upgrade.

Anonymous

Backing up the Confluence installation directorycom.install4j.runtime.beans.actions.files.CreateZipFileAction failedIgnore [i, Enter], Quit [q]iDeleting the previous Confluence installation directory...Error while attempting to remove the previous installation directory. Some files may be in use. Please close all related programs and try again.

and

$ ls -l confluencetotal 0

I see why I'm instructed to back up so often.

This failed presumably because the parent of my installation directory is not writeable. (containment, you know?). But why would the installation be allowed to continue? And why can't the installation just happen in place? Any decent administrator already has backups covered. This hand-holding is unnecessary.

Hi, sounds like the best way to go for you would be to switch to the hosted offering of confluence. This way you wouldn't need to get into the technical details of running confluence and new versions will be available to you as soon as we release them.

I took all the below backups before upgrading from 4.1.7 to 4.3 , what in case I have to do roll things back if upgrade fails.

1.Back up of Confluence Home Directory.2.Back up of database.3.Back up of Confluence Installation directory or Confluence webapp.4.If Attachments and index files are located outside your Confluence Home Directory, then backups of these directories must be performed manually.

In order to rollback you would need to delete the newly installed version and restore the data that you have just backed up. We don't have a dedicated page that lists the rollback steps, but this page might be useful for you.

Anonymous

We have upgrade our confluence from 4.0 to 4.3 successfully. But on Dashboard, there are lots of pages show "Corrected links that should have been relative instead of absolute.". How can we correct it? Thank you.

I am on Confluence 3.5.17 using Adaptavist Theme Builder 4.2.3 which is supported

I upgraded to Confluence 4.2.4 using the Windows installer. Once it finished, my login page was a mess to the point I could not even login. There were error messages on the login page and I picked out this:

com.adaptavist.confluence.builder.macros.tools.ShowMacro

It appears that I need a new version of the Theme Builder plugin. It is a catch22 though, I cannot not install the new Them builder plugin because I cannot login. Any suggestions?

If this doesn't work another possible way is to disable the plugin by modifying data in the database and then restarting the server. Once the plugin is disabled confluence will fall back to the default theme and you will be able to log in and install the new version of the theme builder. Can you please contact support and they will help you out.

I'm a bit puzzled: header in this space says Confluence 5.1 developer (EAP) releases only, but official download page (linked by this page) points to 5.1 archives as if 5.1 was the latest official downloadable release. What version shall we upgrade to in production, 5.0.3 or 5.1? Thanks

I am trying to upgrade from 4.1 to 5.1. When I run the installation wizard and select upgrade an existing confluence installation and my current version it says that my home directory can not be the same as my installation directory.

Hi Ray, you should be able to upgrade directly to 5.1.2. When upgrading please keep in mind that we have made a lot of changes to Confluence's UI in v5.0 and if you would need to upgrade your plugins to compatible versions. More info: Confluence 5.0 Upgrade Notes

I've raised this as
CONF-31370
-
Likes functionality can be broken if a following user no longer exists and the site allows anonymous accessResolved
and we will aim to have it resolved in a 5.3.x bug-fix release, soon.

Hi Anonymous, I strongly suggest you have a look at our guide to upgrading from Confluence 3.5 - there is not a direct upgrade path from 3.4 to Confluence 5 versions due to some very significant changes in Confluence 4 and 5.

Anonymous

Can I upgrade Windows Confluence from running 4.3.3 directly to 5.4 in one shot instead of multiple upgrades?

I noticed that "If your version of Confluence is earlier than 5.1, read the release notes and upgrade guides for all releases between your version and the latest version" in 5.4 release note. But I didn't see any restriction for an upgrade from 4.3.3directly to 5.4, nor were there any mysql databasepre-upgrade requirements.

I have already made backups and run Windows 5.4 installer with upgrade option. It's straightforward and end with "Installation of Confluence 5.4 is Complete" page. But my upgraded Confluence 5.4 server was up with a lot of errors in the log hence the administration drop down list does not work. Anything was missed?

I have upgraded confluence from 4.1.6 to 5.4.2 in our test environment successfully without any major issues but page content is not visible. I checked the layout, stylesheets, themes etc found all are set to default. Though I had truncated the decorator table, there is no change. Any suggestions please?

If your installation directory is a symlink, the upgrade will delete the symlink and create a regular directory instead. If you think you edited the Context in server.xml correctly but still get "Page Not Found" (404) for all pages, then you might have edited the wrong server.xml, i.e. the one in the previous installation directory, probably because you had the folder open, and didn't realize the symlink.

Wow... This upgrading guide is well documented, very detailed etc. But it would be greater to simplify the upgrade procedure and automate it. It's nice to have new features and stuff in the new available version but this upgrading procedure is putting a brake on it. I'd rather have an automated upgrading than new features...

We have a very old version of confluence (2.4.4 build #707) and we are upgrading to Confluence 5.

I am not in charge of the upgrade but need to migrate the content for our group (about 200 pages) to the new version. I have been unable to find any documents on a semi-automated way to do so. Here are my questions.

Is there a way to harvest the content (in WIKI markup) from the old version from a given root node?

If answer to above is yes, is there a way to import it into a space in the new one?I am not asking for a seamless transfer and am happy to manually edit the new pages. I just would rather not transfer each page manually.

Is there a way to do a regular expression search for specific URLs? I want to be able to get all links to other confluence pages in the content above so I can identify the relevant documents and manually replace links to the appropriate new content.

True to form, Atlassian has made it impossible to ask a direct question to support. Why do I say so? Here are the links on the support page:

Search thru docs, KB, bugs or answers (which I already did)

Technical docs

Knowledge base

Answers

Bug tracker

Atlassian Experts (outside parties whom I have to pay)

Translation to plain english: "Pay us first if you want to talk to us or you're on your own (and we don't care if you already bought our stuff)".

By now, I've wasted 2 hours on finding answers to what would seem to be relatively trivial questions. No answers on google and no answers on Atlassian website. I've had this exact experience with Atlassian before when I worked at another company.

Yes, I'm frustrated. Why? Because when I work with organizations like Amazon, Nordstrom or Costco, I actually feel like they want to talk to me as a customer. Here, I'm feeling like the last thing Atlassian wants is actually to talk to a customer.

Let see if anyone at Atlassian will read this. If you do, know that you're actively building up a bad reputation with this customer.

Hi Michael, I'm so sorry you've had such a bad experience today. Support really are the right people to help you (and they do want to talk to you). If you go to https://support.atlassian.com/servicedesk/customer/csp - you'll be prompted to log in, if you don't already have an account, you can create one (free), and then select Installation Query - there you can drop in all your questions above.

I'm afraid I don't know the answers to your questions, but support have a lot of experience working with older versions of Confluence and will be able to help you.

I'll also follow up with that team on why it is so hard to create an issue from the homepage. We're doing a bad job of making it easy to create a support request.

Thanks Rachel. I have nothing personal against you. In fact, I appreciate your willingness to jump in promptly and help.

My frustration is with Atlassian support and the policies. I feel I'm getting the same kind of run around I'd get at the "customer service" with my phone or cable company and that's not saying much. Even for a $5 purchase from Amazon, I get a lot better customer service than this.

In any event, thank you for your prompt responses and assistance. I'm grateful for the same.

Sorry for the frustrating support experience so far. I see you've got an open support ticket with us to address the technical questions, I'll organise one of my colleagues in the US to contact you directly about how we can improve the support experience for you.

I'm still wondering, why a Confluence instance with manual customisations is autostarted after an upgrade. The updater checks & reports the changes, so if it knows there have been changes which must be reapplied after upgrade why does it autostart Confluence?

In most cases, the first start after an upgrade fails with various errors until the modifications are reapplied.

So, please, if the updater finds a modification, make the autostart after upgrade optional & ask the admin...

The documentation on this page says that a 4.3 installation can upgrade directly to the latest version of Confluence, but tech. support is adamant that 4.3 can only upgrade to version 5.0.3, and then 5.0.3 must be upgraded to the latest.

Apologies for that misunderstanding, from 4.3 you can go directly to latest version. The reason why we sometimes give the path to 5.0.3 for customers on 4.3 is because it's a very stable version and in case the upgrade to latest fails for any other reason you would be able have your instance on a stable supported version (5.0.3) while we work on the upgrade problem (in case you had one ).

In a upgrade path perspective, yes you can go from 4.3.3 directly. As Neil replied to you as well make sure to do the upgrade in test so we can avoid any issues in production (when applying in prod remember the golden rule - Backups!!).