Hi, I am currently in the process of migrating our server from an existing Bitnami based deployment (quite an old version) to the officially supported install in AWS using the latest Discourse release. This new install has an external Elasticache and RDS instance and also will use S3 for backups and uploads. I have 2 questions: The old Discourse server is on a pretty old version - by doing the backup/restore in the new Discourse server will that just run all the relevant upgrade commands? If I copy the backup file into the new Discourse docker container on the new server and initiate the restore on the command line, will the new bucket values I set in my config be overwritten as part of the restore or will my new values be used? I assume my new DB is populated from the backup and then when I exist the container and run ./launcher rebuild app my new S3 values will be used. If my assumptions are correct, then before I perform the restore I assume I should copy the contents of the old S3 buckets to the new ones? Are there any other gotchas for doing this type of migration with a backup? Thanks in advance.

Maybe I am missing something but, why are you establishing new buckets? A new backup bucket with appropriate lifecycle rules seems ok to do but if your existing Discourse instance is using S3 upload bucket you will have some problems.

2 reasons we need new buckets: I am not 100% sure the migration from Bitnami will work without a hitch so we don’t want to impact any existing data incase we need to abort the migration We changed our bucket naming so thought it easier to have 2 brand new buckets for this Point 1 is the one that worries me so just being extra careful. What issues do you envisage with the new uploads bucket? The old Discourse server will be put into read only mode. The plan is once the new server is up and validated we will stop our old server, change the DNS to the new server and then purge the cache in the CDN (Cloudfront) and then open it up to the public.

I missed that you were going to copy over the data from the old buckets. Took a look at AWS, looks to be straight forward. If it were me I would not muck with changing buckets before moving to AWS or a new server elsewhere. [image] stevejr: to the officially supported install in AWS using the latest Discourse release. Officially supported?? Not so sure about that. Strongly suggest you get Discourse updated before the move to a new server. On the old instance, suggest you move the S3 config to the app.yml if not there already before moving.

[image] stevejr: I am not 100% sure the migration from Bitnami will work without a hitch This is something you can easily test without affecting production. Personally I would do everything I could to avoid doing these two things at the same moment. see if you can avoid moving buckets at all if you can’t, do it after the migration from Bitnami

[image] stevejr: This new install has an external Elasticache and RDS instance and I am very curious about how doing this type of install is a value added proposition. From the numerous posts around unsupported installs it seems more trouble than benefit unless folks are doing them for learning/experimentation.

[image] philh: am very curious about how doing this type of install is a value added proposition. From the numerous posts around unsupported installs Such a setup might be an unsupported install from a Discourse point of view, but from the perspective of an enterprise IT organisation, RDS and Elasticache might be standard and the Discourse standard install would be the odd one out.

Thanks for that. So familiarity and perhaps existing infrastructure.

Thanks for the input on this question. As mentioned by @RGJ , our enterprise infra uses external services for things like cache, database etc hence the Elasticache and RDS. It means we can have full backup and redundancy for these services and also help with security controls. This is an official/supported installation from a Discourse point of view - its just using a different set of templates - we use discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (maybe using the word standard was a bit misleading, apologies). So, sounds like we should first update our bucket names for the existing install and then perform the move to the new server. Updating the existing install to the latest version is a no go - we experienced issues with the Bitnami upgrade previously hence the move to the official installation method. Can I ask though, what issues are likely to happen if we perform the restore with the existing buckets and then update the app.yml to reference the new buckets - don’t all of the DISCOURSE_ env vars take precedence over any config in the database (if applicable)? Or is there something else that could cause a problem?

[image] stevejr: sounds like we should first update our bucket names for the existing install and then perform the move to the new server I wouldn’t do that [image] RGJ: do it after the migration from Bitnami Since if you do it prior to the migration and things go south, you’ll have the issue on the older Bitnami instance instead of your freshly installed standard instance. And, besides the old version, even the mention of the word Bitnami will make you get far, far less support here on meta. [image] stevejr: don’t all of the DISCOURSE_ env vars take precedence over any config in the database Yes they do.

Ah sorry Richard, misread you bullet point on the S3 name changes :+1: So, better plan is to backup the existing buckets, do the migration, make the bucket name change. Thanks for all your help with this so far. And yes, the “B” word does make people clam up so good to be moving away from it :slight_smile:

Migrating to a new server that has a new DB and new S3 buckets for backup and uploads

Product Support Self-hosting

stevejr (Steve) February 25, 2026, 2:05pm 20

Hi all,

Just wanted to say we did our migration yesterday and it went almost as smooth as butter which was very, very satisfying.

Thank you all for your help with this.

Topic		Replies	Views
Migration to a Self-Hosted solution from Kubernetes Self-hosting install , migrations-tooling	2	495	October 16, 2025
How to migrate Discourse from one server to another with the same DNS name Self-hosting	11	3783	April 12, 2024
Transfer from bitnami to normal discourse Self-hosting	7	3001	June 7, 2019
Help restoring - system hung at midnight Self-hosting	26	2946	June 13, 2022
Error upgrading 2.3.5 to 2.4.2 Self-hosting unsupported-install	16	1255	May 4, 2020

Migrating to a new server that has a new DB and new S3 buckets for backup and uploads

Related topics