diff --git a/README.md b/README.md
index 0647faa18c7..c0823a6fa0f 100644
--- a/README.md
+++ b/README.md
@@ -10,14 +10,14 @@ If you are interested in coordinating the development of new features, please co
 
 ## 🌳 Branching and Release Strategy
 
-cBioPortal is currently preparing for **v7**. The branching and release strategy has been updated as follows:
+cBioPortal has officially released **v7**. The branching and release strategy is as follows:
 
-- **`master` branch** is now the **pre-release branch for v7**. Pull requests targeting v7 should be opened against `master`.
-- **v7** introduces a **ClickHouse-only database**. This new database setup **is not compatible** with earlier portal settings, the traditional MySQL mode, or existing study importer tools.
-- To support existing deployments of v6, we have created a **`maintenance-v6` branch**:
+- **`master` branch** is the **primary development branch for v7**. All new feature development and bug fixes should target `master`.
+- **v7** uses **ClickHouse as the sole database backend**. This setup **is not compatible** with earlier portal settings, the traditional MySQL mode, or existing study importer tools.
+- To support existing deployments of v6, we maintain a **`maintenance-v6` branch**:
     - Only **important security fixes** will be merged into `maintenance-v6`.
     - **No new bug fixes or feature development** will be done on v6.
-    - Users still running v6 should continue to track `maintenance-v6` for necessary security updates.
+    - Users still running v6 should track `maintenance-v6` for security updates.
 
 See more details at [Versioning-and-Upgrades.md](docs/Versioning-and-Upgrades.md)
 
diff --git a/docs/Migration-Guide.md b/docs/Migration-Guide.md
index 26a67732cee..b045f4768ce 100644
--- a/docs/Migration-Guide.md
+++ b/docs/Migration-Guide.md
@@ -2,6 +2,12 @@
 
 This page describes various changes deployers will need to make as they deploy newer versions of the portal.
 
+## v6 -> v7
+- **Database Transition**: v7 replaces MySQL with **ClickHouse** as the sole database backend. MySQL is no longer supported for v7 deployments.
+- **Study Re-import Required**: Existing MySQL data cannot be directly migrated. All studies must be **re-imported** using v7-compatible importer tools.
+- **Configuration**: v7 introduces significant configuration changes. Please review the [Versioning and Upgrade Guide](./Versioning-and-Upgrades.md) for detailed instructions.
+- **Maintenance**: v6 is now in maintenance mode (security fixes only) on the `maintenance-v6` branch.
+
 ## v6.3 -> v6.4
 - The [v6.4.0](https://github.com/cBioPortal/cbioportal/releases/tag/v6.4.0) release includes database schema changes that aren’t backward compatible. Please review the [Database Migration Guide](https://docs.cbioportal.org/updating-your-cbioportal-installation/#running-the-migration-script) before upgrading.
 
diff --git a/docs/deployment/docker/README.md b/docs/deployment/docker/README.md
index 29be29f2644..7db479422c4 100644
--- a/docs/deployment/docker/README.md
+++ b/docs/deployment/docker/README.md
@@ -158,7 +158,10 @@ at [these notes](notes-for-non-linux.md) to allocate more memory for the
 virtual machine in which all Docker processes are running.
 
 ## Clickhouse Mode ##
-For cBioPortal instances with large cohorts (>100K samples), we developed a "Clickhouse mode" of the Study View. This mode uses Clickhouse as an additional database next to MySQL for 10x faster querying (see [video](https://www.youtube.com/watch?v=8PAJRCeycU4)). The mode is experimental and is currently used only by the public-facing [GENIE instance](https://genie.cbioportal.org). We plan to roll it out to other portals later this year (see [roadmap ticket](https://github.com/orgs/cBioPortal/projects/16?query=sort%3Aupdated-desc+is%3Aopen&pane=issue&itemId=92222076&issue=cBioPortal%7Croadmap%7C1)). Follow the steps below to run cBioPortal Docker Compose in clickhouse mode.
+
+cBioPortal has officially released **v7**, which uses **ClickHouse as the sole database backend**. This is now the standard architecture for the portal. For more information on the v7 release and its database requirements, please refer to the main [cBioPortal README.md](../../../README.md#🌳-branching-and-release-strategy).
+
+For legacy v6 deployments (experimental Clickhouse mode alongside MySQL), see the instructions below:
 1. Modify [.env](https://github.com/cBioPortal/cbioportal-docker-compose/blob/master/.env) to use release >= 6.0.27 of cBioPortal.
     ```text
     ...
@@ -169,7 +172,7 @@ For cBioPortal instances with large cohorts (>100K samples), we developed a "Cli
     ```shell
     ./init.sh
     ```
-3. Start cBioPortal with clickhouse
+3. Start legacy cBioPortal with clickhouse
     ```shell
     docker compose -f docker-compose.yml -f addon/clickhouse/docker-compose.clickhouse.yml up
     ```
diff --git a/docs/development/Release-Procedure.md b/docs/development/Release-Procedure.md
index 28e405fc48d..d49067d1224 100644
--- a/docs/development/Release-Procedure.md
+++ b/docs/development/Release-Procedure.md
@@ -7,7 +7,13 @@ We have release procedures for the following scenarios:
 
 ## cBioPortal community release of code already in production
 
-We often run code in production that is not ready yet for use by the wider cBioPortal community. The frontend gets deployed to production after every merge to master. The backend gets updated every Tuesday before our community call (occasionally more frequently too if issues are identified). We tag whatever is in the master and frontend repo and put a "Pre-Release" indication on it. After a month of stable usage in production, one of the tags will get the "latest" indication on the GitHub. These are the steps we follow to create a release:
+We often run code in production that is not ready yet for use by the wider cBioPortal community. The frontend gets deployed to production after every merge to master. The backend gets updated every Tuesday before our community call (occasionally more frequently too if issues are identified). We tag whatever is in the master and frontend repo and put a "Pre-Release" indication on it. After a month of stable usage in production, one of the tags will get the "latest" indication on the GitHub.
+
+**Note on Branching:**
+- **v7** is the current major version, developed on the `master` branch.
+- **v6** is in maintenance mode on the `maintenance-v6` branch (security fixes only).
+
+These are the steps we follow to create a release:
 
 1. Create a new frontend tag. The releases can be found here: https://github.com/cBioPortal/cbioportal-frontend/releases. A draft of the release notes are automatically generated by https://github.com/marketplace/actions/release-drafter. If there are pull requests in the `Changes` section i.e. they have not been labeled with one of the labels defined [here](https://github.com/cBioPortal/cbioportal-frontend/blob/master/.github/release-drafter.yml). Try to label them and trigger a rerun by committing something to the master branch. Alternatively you can manually put them in a particular section. Note that our goal is to have automated release notes, so it would be great if you could send a PR to update the [release-drafter.yml](https://github.com/cBioPortal/cbioportal-frontend/blob/master/.github/release-drafter.yml) in case you find certain PRs don't fit in a particular section or a section should be altered. Look at other release notes for inspiration: https://github.com/cBioPortal/cbioportal-frontend/releases. You can save your work as a draft if necessary.
 2.  Once the frontend code is tagged, create a pull request to the backend repo where the frontend version is incremented in `portal/pom.xml`:
diff --git a/src/main/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImpl.java b/src/main/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImpl.java
index 4bdbc6782f2..7764dc525b3 100644
--- a/src/main/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImpl.java
+++ b/src/main/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImpl.java
@@ -64,7 +64,8 @@ public class UuidDataAccessTokenServiceImpl implements DataAccessTokenService {
 
   private static final Logger log = LoggerFactory.getLogger(UuidDataAccessTokenServiceImpl.class);
 
-  // create a data access token (randomly generated UUID) and insert corresponding record into table
+  // create a data access token (randomly generated UUID) and insert corresponding
+  // record into table
   // with parts:
   // username
   // uuid
@@ -102,6 +103,9 @@ public List<DataAccessToken> getAllDataAccessTokens(String username) {
   public DataAccessToken getDataAccessToken(String username) {
     List<DataAccessToken> allDataAccessTokens =
         dataAccessTokenRepository.getAllDataAccessTokensForUsername(username);
+    if (allDataAccessTokens.isEmpty()) {
+      return createDataAccessToken(username);
+    }
     DataAccessToken newestDataAccessToken = allDataAccessTokens.get(allDataAccessTokens.size() - 1);
     return newestDataAccessToken;
   }
@@ -184,9 +188,11 @@ public Authentication createAuthenticationRequest(String token) {
 
     // when DaoAuthenticationProvider does authentication on user returned by
     // PortalUserDetailsService
-    // which has password "unused", this password won't match, and then there is a BadCredentials
+    // which has password "unused", this password won't match, and then there is a
+    // BadCredentials
     // exception thrown
-    // this is a good way to catch that the wrong authetication provider is being used
+    // this is a good way to catch that the wrong authetication provider is being
+    // used
     return new UsernamePasswordAuthenticationToken(userName, "does not match unused");
   }
 }
diff --git a/src/test/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImplTest.java b/src/test/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImplTest.java
index fbe77596418..55050eb6217 100644
--- a/src/test/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImplTest.java
+++ b/src/test/java/org/cbioportal/legacy/service/impl/UuidDataAccessTokenServiceImplTest.java
@@ -87,8 +87,10 @@ public class UuidDataAccessTokenServiceImplTest {
   @Value("${dat.ttl_seconds}")
   private int datTtlSeconds;
 
-  /* Test for creating a token when autoexpire is on
-   * tests that new token is created/MaxNumberTokensExcceededException is not thrown
+  /*
+   * Test for creating a token when autoexpire is on
+   * tests that new token is created/MaxNumberTokensExcceededException is not
+   * thrown
    * deletedToken should be the oldest token
    */
   @Test
@@ -153,7 +155,8 @@ private boolean createdDataAccessTokenWithWrongInformation(
     return createdDataAccessTokenWithWrongInformation;
   }
 
-  /* Tests validation of a token which is not in the repository
+  /*
+   * Tests validation of a token which is not in the repository
    * Should return false
    */
   @Test
@@ -166,7 +169,8 @@ public void validateNonexistantTokenTest() {
     }
   }
 
-  /* Tests validation of a token when there is a failure retrieving the token
+  /*
+   * Tests validation of a token when there is a failure retrieving the token
    * Should return false
    */
   @Test
@@ -179,8 +183,10 @@ public void validateFailedToGetToken() {
     }
   }
 
-  /* Tests validation of a token which has expired
-   * Mock is configured to test a token with expiration date 100000 seconds before current time
+  /*
+   * Tests validation of a token which has expired
+   * Mock is configured to test a token with expiration date 100000 seconds before
+   * current time
    * Should return false
    */
   @Test
@@ -193,8 +199,10 @@ public void validateExpiredTokenTest() {
     }
   }
 
-  /* Tests validation of a valid token
-   * Mock is configured to test a token with expiration date 100000 seconds after current time
+  /*
+   * Tests validation of a valid token
+   * Mock is configured to test a token with expiration date 100000 seconds after
+   * current time
    * Should return true
    */
   @Test
@@ -206,4 +214,12 @@ public void validateValidTokenTest() {
       Assert.fail("Validation of valid token returned false, expected true.");
     }
   }
+
+  @Test
+  public void testGetDataAccessTokenWhenNoTokensExist() {
+    DataAccessToken token =
+        uuidDataAccessTokenServiceImpl.getDataAccessToken("USER_WITH_NO_TOKENS");
+    Assert.assertNotNull(token);
+    Assert.assertEquals("USER_WITH_NO_TOKENS", token.getUsername());
+  }
 }