diff --git a/content/cn/docs/config/config-backend-hstore.md b/content/cn/docs/config/config-backend-hstore.md
index 59a0131b0..d4606a3aa 100644
--- a/content/cn/docs/config/config-backend-hstore.md
+++ b/content/cn/docs/config/config-backend-hstore.md
@@ -208,3 +208,19 @@ curl http://localhost:8080/metrics/backend
 ```
 
 响应中的 `nodes` 就是 PD 返回的活跃 Store 数量。`nodes` 为 `0` 说明 Server 连上了 PD，但 PD 中没有状态为 `Up` 的 Store，通常是 Store 节点还没注册，或者因为不在 PD 的 `pd.initial-store-list` 中而注册成了 `Pending`。
+
+### 9 旧 GraphID 升级预检
+
+HugeGraph-Store 在启动和升级流程中提供旧版 GraphID 的安全预检保护机制。已发布的 1.7.0 及更早版本不包含此预检保护。
+依赖下述拒绝行为前，请确认使用支持该特性的 Store 构建。
+
+这些 Store 构建会在分配缺失的图 ID、元数据启动阶段首次打开尚未缓存的分区 DB、启动该分区的 Raft 状态机，或激活暂存快照前检查已有图数据列族。
+首次打开时会在清理旧版本前检查所有仍保留的有效 DB 版本。发现保留前缀 `FFFE` 的旧数据时会拒绝操作；
+如果选中的不完整 DB 版本缺少 `CURRENT`、会遮蔽仍保留的有效版本，也会拒绝。
+这针对受影响的旧写入路径，不表示所有 1.7 数据库都需要迁移，持久化 ID 格式保持不变。
+
+遇到拒绝时，保留原始数据 DB 版本、元数据、WAL，以及输入快照和暂存副本，在恢复写入或回放前调查相关写入与升级历史。
+不要删除图到 ID 的映射，也不要把所有保留前缀行归给同一个图，因为不同图可能共享该前缀。Store/Raft 位置元数据可能已在预检前更新，因此整个启动流程并非只读。
+预检不会自动迁移数据或修复归属；完整的 1.7 升级与恢复仍需针对具体部署验证。
+
+详细行为与处置依据见官方升级指南中的 [Store GraphID 升级说明](https://github.com/apache/hugegraph/blob/master/docs/store-graphid-upgrade.md)。
diff --git a/content/en/docs/config/config-backend-hstore.md b/content/en/docs/config/config-backend-hstore.md
index 189ade32c..72d15e633 100644
--- a/content/en/docs/config/config-backend-hstore.md
+++ b/content/en/docs/config/config-backend-hstore.md
@@ -246,3 +246,22 @@ curl http://localhost:8080/metrics/backend
 The `nodes` value in the response is the count of active stores PD returns. A `nodes` value of `0` means the
 Server reached PD but PD has no store in state `Up`, which usually means the Store nodes have not registered
 yet, or registered as `Pending` because they are not in PD's `pd.initial-store-list`.
+
+### 9 Legacy GraphID upgrade preflight
+
+HugeGraph-Store provides legacy GraphID upgrade preflight checks during bootstrap and upgrade processes.
+Released 1.7.0 and earlier Store builds do not contain this preflight guard.
+Use a Store build supporting this capability before relying on the refusal behavior below.
+
+These Store builds check existing graph-data column families before allocating a missing graph ID, first opening a cold
+partition DB during metadata bootstrap, starting its Raft state machine, or activating a staged snapshot. Before pruning, the first cold DB open checks
+all retained valid versions. Reserved `FFFE` legacy rows cause refusal.
+An incomplete selected DB version without `CURRENT` is also rejected when it would hide retained valid versions. This concerns affected old write paths;
+it does not mean that every 1.7 database needs migration, and the persisted ID format is unchanged.
+
+On refusal, preserve the original data DB versions, metadata, WAL and incoming/staged snapshots. Investigate the affected write and upgrade history before
+resuming writes or replay. Do not delete graph-to-ID mappings or assign all reserved-prefix rows to one graph: different graphs may share that prefix.
+Store/Raft location metadata may already have been updated before the check, so the entire bootstrap is not read-only. The check performs no automatic
+migration or ownership repair; a complete 1.7 upgrade and recovery still require deployment-specific validation.
+
+See the [Store GraphID upgrade documentation](https://github.com/apache/hugegraph/blob/master/docs/store-graphid-upgrade.md) for details.