diff --git a/doc/source/admin/migrating_to_gunicorn.md b/doc/source/admin/migrating_to_gunicorn.md
index 84cc031904c..f5ed9566f40 100644
--- a/doc/source/admin/migrating_to_gunicorn.md
+++ b/doc/source/admin/migrating_to_gunicorn.md
@@ -16,30 +16,30 @@ from the actual implementation.
 Note that not all API endpoints have been modernized as of yet, this is an ongoing process.
 
 To see the API documentation for your Galaxy server you can go to `<galaxy_url>/api/docs`.
-Another immediate advantage is that all incoming Parameters are validated against a [Pydantic](https://pydantic-docs.helpmanual.io/) schema.
+Another immediate advantage is that parameters to all incoming API requests are validated against a [Pydantic](https://pydantic-docs.helpmanual.io/) schema.
 This will lead to fewer subtle bugs and make it easier to interface with Galaxy's API.
 
 In the future we are going to use Websockets and asynchronous programming to increase the reactivity
-of history events in Galaxy. This would not be as simple under uWSGI.
+of the Galaxy user interface. This would not be as simple under uWSGI.
 
 ## How do I upgrade my instance to use Gunicorn
 
-If you are using `run.sh` to start Galaxy and have not set up job handling via uWSGI mules
+If you are using `run.sh` to start Galaxy and have not set up job handling via uWSGI mules,
 you do not need to do anything to start Galaxy under Gunicorn.
 
-If you are using uWSGI mules please read the [Scaling and Load Balancing Documentation](scaling.md).
+If you are using uWSGI mules, please read the [Scaling and Load Balancing documentation](scaling.md).
 You will most likely want to set up the **Gunicorn + Webless** strategy.
 
 If you are using an upstream proxy server such as NGINX or Apache and you've been
-using the the uWSGI protocol you need to replace `uwsgi_pass` and `mod_proxy_uwsgi`.
+using the uWSGI protocol, you need to replace `uwsgi_pass` and `mod_proxy_uwsgi`.
 You can find detailed documentation in the [NGINX](nginx.md) and [Apache](apache.md)
 documentation.
 
-If you are managing your Galaxy server via Ansible you can continue to run Galaxy
+If you are managing your Galaxy server via Ansible, you can continue to run Galaxy
 under uWSGI while we are working on updating the Ansible roles for installing Galaxy.
 We will update instructions here and on the [Galaxy Training Network](https://training.galaxyproject.org/).
 
 If you are starting Web and Job Handlers using an external process manager like
-systemd or supervisor please read the [Scaling and Load Balancing Documentation](scaling.md).
-As mentioned in the scaling documentation, you can use [gravity](https://github.com/galaxyproject/gravity) to generate supervisor configuration files
+systemd or supervisor, please read the [Scaling and Load Balancing documentation](scaling.md).
+In particular, you can use [gravity](https://github.com/galaxyproject/gravity) to generate supervisor configuration files
 that you can either use directly or as a basis to update your existing configuration.