diff --git a/site/guide/01-upgrading.md b/site/guide/01-upgrading.md
index a6511c3f..5a037ac8 100644
--- a/site/guide/01-upgrading.md
+++ b/site/guide/01-upgrading.md
@@ -1,856 +1,6 @@
# Upgrading
-Rocket v0.5 bring many new features and improvements over Rocket v0.4. Rocket
-v0.5 also includes many changes that improve the overall usability, stability,
-and security of the framework and applications written in it. While the Rust
-compiler can guide you through many of these changes, others require special
-attention. The intent of this guide is to guide you through these changes and
-more, migrating your Rocket application to 0.5 and reaping the benefits of new
-features and improvements.
-
-This guide is _not_ intended to replace, but instead complement, a reading of
-the [CHANGELOG]. The [CHANGELOG] should be considered required reading for all
-developers wishing to migrate their applications to Rocket v0.5.
-
-[CHANGELOG]: @github/CHANGELOG.md
-
-! note Don't panic!
-
- Simply upgrading Rocket's version string to the `0.5` series will result in
- _many_ `rustc` compiler errors. But don't let this faze you! The vast majority
- of changes are simple renames and `#[async_trait]` attributions which manifest
- in a cascading of errors. As such, resolving _one_ top-level issue, typically
- requiring minimal, trivial changes, often resolves _many_ errors in one go.
-
-## Crate Organization
-
-Rocket v0.5 incorporates an improved module structure and crate ecosystem.
-Modules and items that have been moved or removed will trigger a compiler error.
-We encourage users to search through the [CHANGELOG] or [API docs](@api/rocket)
-for the v0.5 analog. All previously existing functionality, except for that
-incompatible with async I/O, is available in v0.5.
-
-### Off-by-Default Secrets
-
-The `private-cookies` crate feature, which was previously enabled by default,
-has been renamed to `secrets` and is disabled by default. If you are using
-private cookies, you _must_ enable the `secrets` feature in `Cargo.toml`:
-
-```toml
-[dependencies]
-rocket = { version = "0.5.0", features = ["secrets"] }
-```
-
-### Contrib Deprecation
-
-The `rocket_contrib` crate is deprecated and is wholly incompatible with Rocket
-0.5. _All_ users of `rocket_contrib` _must_:
-
- * Remove all dependencies and references to `rocket_contrib`.
- * For templating support, depend on the new [`rocket_dyn_templates`] crate.
- * For database pools, depend on the new [`rocket_sync_db_pools`] and/or
- [`rocket_db_pools`] crates.
- * Enable [features in `rocket`] as necessary.
-
-For example, to make use of JSON and Tera templates, make the following changes
-to `Cargo.toml`:
-
-```diff
-[dependencies]
-- rocket = "0.4"
-- rocket_contrib = { version = "0.4", features = ["json"], default-features = false }
-+ rocket = { version = "0.5.0", features = ["json"] }
-+ rocket_dyn_templates = { version = "0.1.0", features = ["tera"] }
-```
-
-! note: `rocket_dyn_templates` (and co.) _does not_ follow in version lock-step
-with the `rocket` crate.
-
- This is intentional. The crate depends on many external dependencies which may
- evolve at a different pace than Rocket itself. Allowing their versions to
- diverge enables keeping dependencies up-to-date without breaking `rocket`
- itself.
-
-All features previously in `rocket_contrib` are available. Consult the [contrib
-graduation] section of the CHANGELOG for full details.
-
-[`rocket_dyn_templates`]: @api/rocket_dyn_templates
-[`rocket_sync_db_pools`]: @api/rocket_sync_db_pools
-[`rocket_db_pools`]: @api/rocket_db_pools
-[features in `rocket`]: @api/rocket/#features
-[contrib graduation]: @github/CHANGELOG.md#contrib-graduation
-
-## Stable and Async Support
-
-Rocket v0.5 compiles and builds on Rust stable with an entirely asynchronous
-core. You are encouraged to:
-
- * Switch to the Rust stable release channel for production builds.
- * Remove the previously required `#![feature(..)]` crate attribute.
-
-All application authors _must_:
-
- * Use `rocket::build()` instead of `rocket::ignite()`.
- * Use either the `#[launch]` or `#[rocket::main]` async entry attribute.
- * Use `async` versions of any blocking I/O or execute it in another thread.
-
-Application authors _may_:
-
- * Prefer to explicitly import macros via `use` instead of `#[macro_use]`.
-
-The rest of the section describes making these changes in detail.
-
-### Stable Release Channel
-
-If you prefer to use Rust's stable release channel, you can switch to it using
-`rustup`:
-
-```sh
-## switch globally
-rustup default stable
-
-## switch locally
-rustup override set stable
-```
-
-Using the stable release channel ensures that _no_ breakages will occur when
-upgrading your Rust compiler or Rocket. That being said, Rocket continues to
-take advantage of features only present in the nightly channel. As a result, the
-development experience will be superior on nightly for the foreseeable future.
-For example, compiler diagnostics on `nightly` are more detailed and accurate:
-
-
-Example Diagnostic on Nightly
-
-```rust,ignore
-error: invalid parameters for `has_two` route uri
- --> $DIR/typed-uris-bad-params.rs:55:18
- |
-55 | uri!(has_two(id = 100, cookies = "hi"));
- | ^^^^^^^^^^^^^^^^^^^^^^^^
- |
- = note: uri parameters are: id: i32, name: String
- = help: missing parameter: `name`
-help: unknown parameter: `cookies`
- --> $DIR/typed-uris-bad-params.rs:55:28
- |
-55 | uri!(has_two(id = 100, cookies = "hi"));
- | ^^^^^^^
-```
-
-
-
-
-Example Diagnostic on Stable
-
-```rust,ignore
-error: invalid parameters for `has_two` route uri
- --- note: uri parameters are: id: i32, name: String
- --- help: missing parameter: `name`
- --> $DIR/typed-uris-bad-params.rs:55:18
- |
-55 | uri!(has_two(id = 100, cookies = "hi"));
- | ^^
-
-error: [help] unknown parameter: `cookies`
- --> $DIR/typed-uris-bad-params.rs:55:28
- |
-55 | uri!(has_two(id = 100, cookies = "hi"));
- | ^^^^^^^
-```
-
-
-
-Our **recommendation** is to develop locally on the nightly channel but build
-and deploy for production on the stable channel.
-
-### Feature Attribute
-
-As a result of support for the stable release channel, Rocket applications no
-longer need to enable any features to be used. You should **remove all
-`#[feature(..)]` crate attributes:**
-
-```diff
-- #![feature(proc_macro_hygiene, decl_macro)]
--
- #[macro_use] extern crate rocket;
-
- fn main() { .. }
-```
-
-### Updates to Launch
-
-The new asynchronous core requires an async runtime to run. The new
-[`launch`] and [`main`] attributes simplify starting a runtime suitable for
-running Rocket applications. You should use [`launch`] whenever possible.
-
-Additionally, the `rocket::ignite()` function has been renamed to
-[`rocket::build()`]; calls to the function or method should be replaced
-accordingly. Together, these two changes result in the following diff to what
-was previously the `main` function:
-
-```diff
-- fn main() {
-- rocket::ignite().mount("/hello", routes![hello]).launch();
-- }
-+ #[launch]
-+ fn rocket() -> _ {
-+ rocket::build().mount("/hello", routes![hello])
-+ }
-```
-
-[`launch`]: @api/rocket/attr.launch.html
-[`main`]: @api/rocket/attr.main.html
-[`rocket::build()`]: @api/rocket/struct.Rocket.html#method.build
-
-### Blocking I/O
-
-Rocket v0.5 takes advantage of the latest developments in async I/O in Rust by
-migrating to a fully asynchronous core powered by [`tokio`]. Specifically,
-_every_ request is handled by an asynchronous task which internally calls one or
-more request handlers. Asynchronous tasks are multiplexed on a [configurable
-number of worker threads]. Though there is no limit to the number of tasks that
-can run concurrently, at most `worker` tasks can run in parallel.
-
-The runtime can switch between tasks in a single worker thread _iff_ (_if
-and only if_) an `await` point in reached. In other words, context
-switching is _cooperative_, _not_ preemptive. This _iff_ is critical: if an
-`await` point is _not_ reached, no task switching can occur. As such, it is
-important that `await` points occur periodically in a task so that tasks waiting
-to be scheduled are not starved.
-
-In general, when working with `async` APIs, await points occur naturally.
-However, an application written for synchronous I/O, including all Rocket
-applications prior to v0.5, must take great care to convert all synchronous,
-blocking I/O, to `async` I/O. This is because, as the name implies, blocking I/O
-blocks a thread from making progress until the I/O result is available, meaning
-that no tasks can be scheduled on the waiting thread, wasting valuable resources
-and degrading performance.
-
-Common sources of blocking I/O and their `async` replacements include:
-
- * Anything in `std::fs`: replace with `rocket::tokio::fs`.
- * Anything in `std::sync`: replace with `rocket::tokio::sync`.
- * Anything in `std::net`: replace with `rocket::tokio::net`.
- * Anything in `std::io`: replace with `rocket::tokio::io`.
- * Sleep or timers: replace with `rocket::tokio::time`.
- * Any networking: replace with `rocket::tokio::net`.
- * Any file system access: replace with `rocket::tokio::fs`.
-
-Unfortunately, the Rust compiler provides no support for identifying blocking
-I/O via lints or compile-time checks: it is up to you to scan your application
-for sources of blocking I/O and replace them with their `async` counterpart. If
-no such counterpart exists, you should execute the relevant I/O in its own
-thread by using [`rocket::tokio::task::spawn_blocking`].
-
-All of Rocket's I/O APIs have been updated to be `async`-safe.
-This results in requiring `.await` calls for common APIs like [`NamedFile`]. To
-use `.await` in a route, the handler must be marked with `async`:
-
-```rust
-# use rocket::get;
-use rocket::fs::NamedFile;
-
-#[get("/")]
-async fn index() -> Option {
- NamedFile::open("index.html").await.ok()
-}
-```
-
-! warning: Non-`async` routes are _also_ executed on the `async` runtime.
-
- A route that _isn't_ declared as `async` is _still_ executed on the `async`
- runtime. As a result, it should not execute blocking I/O.
-
-
-See a diff of the changes from v0.4.
-
-```diff
-- use rocket::response::NamedFile;
-+ use rocket::fs::NamedFile;
-
-#[get("/")]
-- fn index() -> Option {
-- NamedFile::open("index.html").ok()
-+ async fn index() -> Option {
-+ NamedFile::open("index.html").await.ok()
-}
-```
-
-
-
-[`tokio`]: https://tokio.rs
-[configurable number of worker threads]: ../configuration/#workers
-[`NamedFile`]: @api/rocket/fs/struct.NamedFile.html
-[`rocket::tokio::task::spawn_blocking`]: @tokio/task/fn.spawn_blocking.html
-
-### Blocking Compute
-
-By the same reasoning, performing large amounts of compute (really, just another
-form of I/O) can prevent other tasks from executing in a timely manner. If you
-are performing long computations in a handler, you should execute the
-computation in its own thread, again using [`rocket::tokio::task::spawn_blocking`]:
-
-```rust
-# use rocket::get;
-use rocket::tokio::task;
-use rocket::response::Debug;
-
-#[get("/")]
-async fn expensive() -> Result<(), Debug> {
- let result = task::spawn_blocking(move || {
- // perform the computation
- }).await?;
-
- Ok(result)
-}
-```
-
-### Async Traits
-
-To support `async` methods in traits, Rocket provides the [`async_trait`]
-attribute. The attribute _must_ be applied to all implementations of _async
-traits_ like [`FromRequest`] and [`Fairing`]:
-
-```diff
-use rocket::request::{self, Request, FromRequest};
-
-+ #[rocket::async_trait]
-impl<'r> FromRequest<'r> for MyType {
- type Error = MyError;
-
-- fn from_request(req: &'r Request<'_>) -> request::Outcome {
-+ async fn from_request(req: &'r Request<'_>) -> request::Outcome {
- /* .. */
- }
-}
-```
-
-All trait documentation has been updated to call out such traits with an example
-implementation that includes the invocation. The example implementation also
-serves as better documentation for trait and trait method signatures than the
-rustdocs. Because `async_trait` modifies these signatures, the rustdocs diverge
-from what is written in the source. For example, rustdoc renders:
-
-```rust,ignore
-fn from_request<'life0, 'async_trait>(
- request: &'r Request<'life0>
-) -> Pin> + Send + 'async_trait>>;
-```
-
-...whereas the source looks like:
-
-```rust,ignore
-async fn from_request(req: &'r Request<'_>) -> Outcome;
-```
-
-Unfortunately, rustdoc does not provide a mechanism to render the source as it
-is written. As such, we encourage all authors to use the examples as the source
-of truth for trait and method signatures.
-
-[`async_trait`]: @api/rocket/attr.async_trait.html
-[`FromRequest`]: @api/rocket/request/trait.FromRequest.html
-[`Fairing`]: @api/rocket/fairing/trait.Fairing.html
-
-## Configuration
-
-Rocket's configuration system has been entirely revamped for v0.5. The
-[configuration](../configuration) section of the guide contains a full
-walkthrough of the new system while the [general changes] section of the
-[CHANGELOG] contains further details on configuration changes. We call out the
-most important of these changes here. All users _must_:
-
- * Replace the `ROCKET_ENV` environment variable with `ROCKET_PROFILE`.
- * Replace the `ROCKET_LOG` environment variable with `ROCKET_LOG_LEVEL`.
- * Use only IP addresses for the `address` configuration parameter.
- * Replace the `dev` or `development` profile with `debug`.
- * Note that the `stage`, `staging`, `prod`, and `production` profiles carry no
- special meaning in v0.5.
- * Use `0` to disable `keep_alive` instead of `false` or `off`.
- * Replace uses of "extras" with [typed extraction].
-
-Rocket will emit warnings at launch time if use of the previous functionality is
-detected.
-
-### Profiles
-
-The new system deals with "profiles" where there were previously "environments".
-As opposed to environments, profiles:
-
- * Can be arbitrarily named and any number can exist.
- * Match Rust profiles in naming: `debug` and `release` are the default
- profiles for the respective Rust compilation profile.
- * Are programmatically selectable and configurable.
- * Have a `default` profile with fallback values for all profiles.
- * Have a `global` profile with overrides for all profiles.
-
-Authors should read the new [configuration](../configuration) section of the
-guide to determine the scope of changes required. This likely includes:
-
- * Defining most configuration in the `default` profile instead.
- * Using the `debug` profile where `dev` or `development` was used.
- * Using the `release` profile where `prod` or `production` was used.
-
-[general changes]: @github/CHANGELOG.md#general
-[typed extraction]: ../configuration/#extracting-values
-
-### Typed Extraction
-
-The "extras" configuration in v0.4 is entirely replaced by [typed extraction],
-which allows any `Deserialize` structure to be derived from configuration
-sources. All users _should_ make use of typed extraction where "extras" were
-being used previously. The diff below illustrates one such example:
-
-```diff
-use rocket::fairing::AdHoc;
-
-+ #[derive(Deserialize)]
-struct AppConfig {
- id: Option,
- port: u16,
-}
-
-- fn main() {
-- rocket::ignite()
-- .attach(AdHoc::on_attach("Token Config", |rocket| {
-- println!("Adding token managed state from config...");
-- let id = match rocket.config().get_int("id") {
-- Ok(v) if v >= 0 => Some(v as usize),
-- _ => None,
-- };
--
-- let port = match rocket.config().get_int("port") {
-- Ok(v) if v => 0 && v < 1 << 16 => v as u16,
-- _ => return Err(rocket)
-- };
--
-- Ok(rocket.manage(AppConfig { id, port }))
-- }))
-- }
-
-+ #[launch]
-+ fn rocket() -> _ {
-+ rocket::build().attach(AdHoc::config::())
-+ }
-```
-
-## Routing
-
-Rocket v0.5 brings several major changes that affect routing:
-
- 1. [Default ranking] is more precise, so fewer routes need manual ranking.
- 2. Multi-segment route parameters (``) now match _zero_ or more
- segments.
- 3. Parameters are _always_ percent-decoded, so `&RawStr` no longer implements
- `FromParam`.
- 4. Query parameters parse with [`FromForm`] instead of `FromQuery` and support
- arbitrarily collections, nesting, structures, etc.
- 5. All UTF-8 characters are allowed in static path components: `#[get("/🚀")]`.
- 6. The [`register()`] method require a path to [scope catchers] under. Using
- `"/"` emulates the previous behavior.
-
-[Default ranking]: ../requests#default-ranking
-[`FromForm`]: @api/rocket/form/trait.FromForm.html
-[`FromParam`]: @api/rocket/request/trait.FromParam.html
-[`register()`]: @api/rocket/struct.Rocket.html#method.register
-[scope catchers]: ../requests/#scoping
-
-### Default Ranks
-
-Default route ranking now takes into account partially dynamic paths, increasing
-the range of default ranks from `[-6, -1]` to `[-12, -1]`. The net effect is
-that fewer routes collide by default, requiring less manual ranking. For
-example, the following two routes collide in v0.4 but not in v0.5:
-
-```rust
-# use rocket::get;
-
-#[get("/foo/<_>/bar")]
-fn foo_bar() { }
-
-#[get("/<_..>")]
-fn everything() { }
-```
-
-
-See a diff of the changes from v0.4.
-
-```diff
-- #[get("/foo/<_>/bar", rank = 1)]
-+ #[get("/foo/<_>/bar")]
- fn foo_bar() { }
-
-- #[get("/<_..>", rank = 2)]
-+ #[get("/<_..>")]
- fn everything() { }
-```
-
-
-**The recommendation** is to remove all unnecessary manual ranking parameters.
-For smaller applications, you may find that _all_ manual ranks can be removed.
-Larger applications may still require ranks to resolve ambiguities.
-
-### Kleene Multi-Segments
-
-The multi-segment route parameter `` now matches _zero or more_ segments,
-a change from the previous _one_ or more segments. The implication is two-fold:
-
- 1. Where previously two routes were required to match a prefix and its
- suffixes, now one suffices:
-
- ```diff
- - #[get("/")]
- - fn index();
-
- - #[get("/")]
- - fn rest(path: PathBuf);
-
- + #[get("/")]
- + fn all(path: PathBuf);
- ```
-
- 2. A prefix collides with a route that matches all of its suffixes. For
- example, `index` and `rest` above collide.
-
-Most applications will likely benefit from this change by allowing the extra
-prefix-only route to be removed entirely. If the previous functionality of
-requiring at least one segment is desired, a route that explicitly matches the
-first segment can be used:
-
-```rust
-# use std::path::PathBuf;
-# use rocket::get;
-
-#[get("//")]
-fn rest(first: PathBuf, rest: PathBuf) { /* .. */ }
-```
-
-### Fewer Raw Strings
-
-Rocket v0.5 makes a concerted effort to limit the exposure to strings from the
-raw HTTP payload. In line with this philosophy, Rocket now percent-decodes all
-incoming parameters automatically as opposed to doing so on-demand. The
-corollary is three-fold:
-
- 1. The `&RawStr` type no longer implements [`FromParam`].
- 2. The `&str` type now implements [`FromParam`] and is fully decoded.
- 3. The `String` parameter type is identical to the `&str` type and should be
- avoided.
-
-Most applications can simply swap uses of `&RawStr` and `String` for `&str` in
-routes, forms, and so on to benefit from the increased safety and performance.
-For instance, the front-page example becomes:
-
-```diff
- #[get("//")]
-- fn hello(name: String, age: u8) -> String {
-+ fn hello(name: &str, age: u8) -> String {
- format!("Hello, {} year old named {}!", age, name)
-}
-```
-
-A form that previously used `String` becomes:
-
-```diff
-#[derive(FromForm)]
-- struct MyForm {
-+ struct MyForm<'r> {
-- value: String,
-+ value: &'r str,
-}
-```
-
-### Queries as Forms
-
-Query strings in Rocket v0.5 are in parity with forms and support their [full
-breadth](../requests#forms). Single segment query parameters (``) should
-require little to no changes, except that they now support collections,
-structures, and any other `FromForm` type. This implies that the majority, if
-not _all_ custom `FromQuery` implementations, should be derivable via `FromForm`
-or have a built-in equivalent like `Vec`:
-
-```rust
-# use rocket::post;
-
-#[post("/?")]
-fn form(numbers: Vec) { /* .. */ }
-```
-
-Multi-segment query parameters (``) no longer require the use of a
-`Form` guard. Instead, `T` can be used directly:
-
-```diff
-#[derive(FromForm)]
-struct Person { /* .. */ }
-
-#[get("/hello?")]
-- fn hello(person: Option