diff --git a/Release-planning-process.md b/Release-planning-process.md
index b190325..07c5fb8 100644
--- a/Release-planning-process.md
+++ b/Release-planning-process.md
@@ -1,19 +1 @@
-We often get questions about how we choose specific features to go into a particular release. 
-
-Of course we have a [roadmap](roadmap), which defines a set of important features we want to support, and we have [a backlog milestone in our issue tracker](https://github.com/aspnet/EntityFrameworkCore/issues?q=is%3Aopen+is%3Aissue+milestone%3ABacklog+sort%3Areactions-%2B1-desc) in which issues can be up-voted, and a few other sources of ideas like [our UserVoice page](https://data.uservoice.com/forums/72025-entity-framework-core-feature-suggestions). But all that that doesn't automatically translate into a release plan.
-
-It is difficult to detail here the whole process we follow to plan a release, partly because a lot of it is discussing the specific features, opportunities and priorities, and partly because the process itself usually evolves with every release. However, it is relatively easy to summarize the common questions we try to answer when deciding what to work on next:
-
-1. **How many developers we think will use the feature and how much better will it make their applications/experience?** We aggregate feedback from many sources into this—Comments and votes on issues is one of those sources.
-
-2. **What are the workarounds people can use if we don’t implement this feature yet?** For example, many developers are able to map a join table in order to work around lack of native many-to-many support. Obviously, not all developers can do this, but many can, and this is a factor which counts.
-
-3. **Does implementing this feature evolve the architecture of EF Core such that it moves us closer to implementing other features?** We tend to favor features that act as building blocks for other features—for example, the table splitting that was done for owned types helps us move towards TPT support.
-
-4. **Is the feature an extensibility point?** We tend to favor extensibility points because they enable developers to more easily hook in their own behaviors and get some of the missing functionality that way. We’re planning to do some of this as a start to the lazy loading work.
-
-5. **What is the synergy of the feature when used in combination with other products?** We tend to favor features that allow EF Core to be used with other products or to significantly improve the experience of using other products, such as .NET Core, the latest version of Visual Studio, Microsoft Azure, etc.
-
-6. **What are the capabilities of the people available to work on a feature, and how to best leverage these resources?** Each member of the EF team and even our community contributors have different levels of experience in different areas and we have to plan accordingly. Even if we wanted to have “all hands on deck” to work on a feature like GroupBy translations, or many-to-many, that wouldn’t be practical.
-
-In the future we would like to add more opportunities for members of the developer community to provide inputs into release plans, e.g. by making it easier to review proposed drafts of the features and of the release plan itself.
\ No newline at end of file
+The [Release Planning Process](https://docs.microsoft.com/ef/core/what-is-new/roadmap#release-planning-process) is now part of the EF Core documentation. 
\ No newline at end of file