diff --git a/docs/xdto-guide.md b/docs/xdto-guide.md
index 4ce8193b..7801c688 100644
--- a/docs/xdto-guide.md
+++ b/docs/xdto-guide.md
@@ -113,11 +113,24 @@
 
 Типовой приём: рядом со старым пакетом появляется новый с другим пространством
 имён (`EnterpriseData_1_19` → `_1_20`), а старые потребители продолжают смотреть
-на прежний namespace.
+на прежний namespace. Копия делается через выгрузку схемы и сборку под новым именем:
 
-Если же надо сменить namespace **у существующего** пакета, агент перепишет все
-внутренние ссылки и перечислит пакеты, которые импортируют старый — но менять
-их не станет, потому что при версионировании это было бы ошибкой.
+1. `/xdto-decompile` исходного пакета в файл схемы;
+2. в схеме поменять `targetNamespace` — **и связанное с ним объявление `xmlns`**,
+   которым внутренние ссылки пользуются как префиксом;
+3. `/xdto-compile` этой схемы с `-Name` нового пакета (имя и синоним задаются
+   флагами, править их внутри схемы не нужно).
+
+Внутренние ссылки при этом переводятся на новый namespace целиком, импорты чужих
+пакетов сохраняются, исходный пакет не меняется.
+
+Менять `targetNamespace` **заменой всех вхождений строки** — плохая идея: если пакет
+импортирует пространство имён, у которого старый URI является префиксом
+(`urn:example:exchange` и `urn:example:exchange:legacy`), заменится и оно.
+
+Если же надо сменить namespace **у существующего** пакета, а не сделать копию, агент
+перепишет все внутренние ссылки и перечислит пакеты, которые импортируют старый — но
+менять их не станет, потому что при версионировании это было бы ошибкой.
 
 ### Отдать схему контрагенту