diff --git a/docs/v1.X/docs/assets/images/crowdsec_architecture.png b/docs/v1.X/docs/assets/images/crowdsec_architecture.png
index 4764c0d2c..94426bdfb 100644
Binary files a/docs/v1.X/docs/assets/images/crowdsec_architecture.png and b/docs/v1.X/docs/assets/images/crowdsec_architecture.png differ
diff --git a/docs/v1.X/docs/getting_started/upgrades.md b/docs/v1.X/docs/getting_started/upgrades.md
index 1ee56669a..b4420dfd9 100644
--- a/docs/v1.X/docs/getting_started/upgrades.md
+++ b/docs/v1.X/docs/getting_started/upgrades.md
@@ -1,31 +1,38 @@
-# Upgrades
+# Upgrade notes
 
-The wizard is here to help the user in the process of upgrading an existing installation.
-Various items need to be kept during the upgrade process:
+Crowdsec does it best not to break existing setups, and the following rules generally applies :
 
- - scenarios/parsers/postoverflows : upstream scenarios need to be updated, while local/tainted ones need to be kept as-is
- - most configurations must be kept as-is (`acquis.yaml` `*_credentials.yaml` `profiles.yaml` `simulation.yaml` `config.yaml`)
- - database (especially if it's a SQLite file)
+ - patches (`X.X.Y` to `X.X.Z`) can be applied blindly and are for bugfixes and backward compatible changes
+ - minor (`X.Y.X` to `X.Z.X`) can be applied blindly but might introduce some features that are not backward compatible
+ - major (`Y.X.X` to `Z.X.X`) must be applied with caution as they might break existing installation
 
 
+!!! warning
+
+    We **strongly** advise you against running crowdsec and LAPI in different versions.
+    When upgrading existing setup, we suggest you to upgrade both crowdsec, cscli and LAPI.
+
+# Upgrades from debian packages (official or pragmatic)
+
+```bash
+apt-get update 
+apt-get install crowdsec
+```
+
+# Upgrades from release tarball
+
 ## Patch upgrade
 
 `wizard.sh --binupgrade`
 
 When doing a minor/patch upgrade (ie. `1.0.0` to `1.0.1`), the `--binupgrade` feature should be the more appropriate : It will simply upgrade the existing binaries, letting all configurations untouched.
 
-As any breaking change should lead to a version bump and appropriate warning, this is the safest option.
-
-
 ## Minor upgrade
 
-
 `wizard.sh --upgrade`
 
 When doing a minor upgrade (ie. `1.0.4` to `1.1.0`), the `--upgrade` feature should be used : It will attempt to migrate and upgrade any existing configurations, include tainted/custom ones. The ambition is to be able to upgrade scenarios, parsers etc to the latest version when relevant, while keeping custom/tainted ones untouched.
 
-
-
 It's using `cscli config backup`, creating a directory (usually `/tmp/tmp.<random>`) in which it's going to dump all relevant configurations before performing an upgrade :
 
  - configuration files : `acquis.yaml` `*_credentials.yaml` `profiles.yaml` `simulation.yaml` `config.yaml`
@@ -41,8 +48,15 @@ For major upgrades (ie. `0.3.X` to `1.0.X`), `wizard` won't do the trick, and yo
  - Migrating from `0.3.X` to `1.0.X` :  [documentation](Crowdsec/v1/migration/)
 
 
-## General warning
+# Manual operations
 
-We **strongly** advise you against running crowdsec and LAPI in different versions.
-When upgrading existing setup, we suggest you to upgrade both crowdsec, cscli and LAPI.
+[`cscli config`](/Crowdsec/v1/cscli/cscli_config/) is your friend here, with [`backup`](/Crowdsec/v1/cscli/cscli_config_backup/) and [`restore`](/Crowdsec/v1/cscli/cscli_config_backup/) subcommands allowing you to backup and restore all of the configuration files.
 
+
+# Upgrading collections/parsers/scenarios
+
+[`cscli hub`](/Crowdsec/v1/cscli/cscli_hub/) allows you to view, update and upgrade configurations :
+
+ - [`cscli hub update`](/Crowdsec/v1/cscli/cscli_hub_update/) downloads the latest list of available scenarios/parsers/etc
+ - [`cscli hub list`](/Crowdsec/v1/cscli/cscli_hub_list/) lists all the installed configurations, their versions and status
+ - [`cscli hub upgrade`](/Crowdsec/v1/cscli/cscli_hub_upgrade/) upgrades existing configurations to the latest available version in said list