Merge pull request magento-commerce/devdocs#3227 from magento-devdocs/COMDOX-365-migration-metadata

COMDOX-365: Add missing migration metadata

Author: jeff-matthews

src/contributor-guide/templates/basic_template.md

@@ -4,6 +4,7 @@ title: Basic template
 redirect_from:
 - guides/v2.3/contributor-guide/templates/basic_template.html
 - guides/v2.4/contributor-guide/templates/basic_template.html
+redirect_to: https://developer.adobe.com/commerce/contributor/guides/doc-contributions/
 ---
 
 Introductory text that gives an overview of the topic you will be writing about.

src/guides/v2.4/architecture/frontend_custom_strategies.md

@@ -0,0 +1,107 @@
+---
+group: architecture-guide
+title: Ease of frontend customization
+migrated_to: https://developer.adobe.com/commerce/php/architecture/basics/frontend-customization/
+layout: migrated
+---
+
+## Overview {#m2arch-whatis-overview}
+
+The Magento [frontend](https://glossary.magento.com/frontend) is designed to optimize [storefront](https://glossary.magento.com/storefront) customization, with highly extensible *themes* being the central customization mechanism.
+
+Merchants are encouraged to use Magento components and themes to extend and transform the appearance of their storefronts.
+
+## Storefront customization tools
+
+Magento provides several tools to help you significantly jumpstart the storefront customization process:
+
+*  Magento Blank [Theme](https://glossary.magento.com/theme)
+
+*  [Overview of UI components][]
+
+*  [Admin Pattern Library][]
+
+See the [Frontend Developer Guide][] for information on creating your themes.
+
+### Magento Blank theme
+
+The Magento blank theme template provides a launchpad for storefront customization. You can use this boilerplate as a robust starting point for your own theme development.
+
+### Magento UI components
+
+Using Magento standard coding and styling tools can help:
+
+*  enforce for consistency in design across your storefronts
+*  simplify (and speed up) the design process
+
+This component [library](https://glossary.magento.com/library) contains standard reusable components for form features, such as fields and buttons, and navigation elements. The Magento UI library is a set of generic web components and Magento-specific patterns, which simplifies the process of Magento theme creation and customization.
+
+See [Overview of UI components][] for details about this library.
+
+### Admin pattern library
+
+A *pattern library* is a collection of user interface (UI) design patterns that can be re-used in locations throughout your product installation. The [Admin Pattern Library][] defines examples of components that administrators working with the storefront can use.
+
+Form elements included in the [Admin](https://glossary.magento.com/magento-admin) pattern library include:
+
+*  address form
+*  button bar
+*  container
+*  tabs
+*  sign-in form
+
+Users of the default Magento storefront encounter examples of these form elements throughout the product. These patterns provide a valuable language of software components (and indirectly, user experiences) for [extension](https://glossary.magento.com/extension) developers and administrators.
+
+The Magento [Admin](https://glossary.magento.com/admin) Pattern library is built on the Less preprocessor and implemented as a [module](https://glossary.magento.com/module). You can download a free, current version of this module from [Commerce Marketplace](https://marketplace.magento.com/).
+
+See [Admin Pattern Library][] for more information on using this library.
+
+## Storefront customization levels
+
+These four levels of potential storefront customization are listed in order to increase complexity.
+
+### Extend Magento-Provided CSS
+
+Magento supplies a default [theme](https://glossary.magento.com/theme) and a Less-based CSS. You can substantially change a storefront using CSS only. This uncomplicated strategy might suit projects with a limited budget, or might interest developers who create different skins for a site. A small business enter this process of storefront customization by buying a third-party developed theme from Commerce Marketplace to extend the default values.
+
+### Replace PHTML template files
+
+In addition to extending the default CSS, you can generate different HTML [markup](https://glossary.magento.com/markup). For example, you might need to add a missing CSS class name, or add an extra `<div>` tag to achieve some visual effect. You might also need to tweak some [JavaScript](https://glossary.magento.com/javascript/) to cope with different HTML markup. This change is more demanding than simply extending Magento CSS, but is still within the grasp of smaller projects and leaner teams.
+
+### Replace Magento-Provided CSS
+
+Rather than edit the default CSS provided by Magento, you might decide to replace all the default storefront CSS code with your own. This strategy avoids tying a project to the Magento-provided CSS, but puts a greater burden on project development and integration. It also allows the use of different CSS tools or technologies not provided with Magento. Partners who build their own set of CSS libraries could reuse these libraries on different customer projects. (These unique CSS libraries may help differentiate a partner from others in the market.)
+
+In addition to replacing CSS files, you might need to replace small amounts of HTML and JavaScript.
+
+### Replace Magento-Provided CSS, HTML, and JavaScript
+
+Delivering a sharply different shopping experience than the default Magento installation provides is a more substantial task. However, the tradeoff might be a more complicated experience integrating additional extensions into your installation in the future.
+
+{:.bs-callout-tip}
+ Any customization of your storefront will work optimally, and provide the easiest path for later upgrades, if you follow the best practice of consistently compartmentalizing code by type. For example, keep all HTML in [PHTML](https://glossary.magento.com/phtml) files; keep all JavaScript in JavaScript files.
+
+{:.ref-header}
+Related topics
+
+[Extensibility and modularity][]
+
+[Global extensibility features][]
+
+[Admin Pattern Library][]
+
+[Overview of UI components][]
+
+[Frontend Developer Guide][]
+
+[JavaScript Developer Guide][]
+
+<!-- Link Definitions -->
+
+[Extensibility and modularity]:{{page.baseurl}}/architecture/extensibility.html
+[Global extensibility features]: {{page.baseurl}}/architecture/global_extensibility_features.html
+[Admin Pattern Library]: {{page.baseurl}}/pattern-library/bk-pattern.html
+[Overview of UI components]: {{page.baseurl}}/ui_comp_guide/bk-ui_comps.html
+[Frontend Developer Guide]: {{page.baseurl}}/frontend-dev-guide/bk-frontend-dev-guide.html
+[JavaScript Developer Guide]: {{page.baseurl}}/javascript-dev-guide/bk-javascript-dev-guide.html
+[Commerce Marketplace]: https://marketplace.magento.com/

src/guides/v2.4/architecture/frontend_custom_strategies.md

@@ -0,0 +1,38 @@
+---
+group: web-api
+title: Getting started with Magento
+menu_title: Getting started with Magento
+menu_order: 1
+menu_node:
+functional_areas:
+  - Integration
+migrated_to: https://developer.adobe.com/commerce/docs
+layout: migrated
+---
+
+## Getting started with Magento {#highlights}
+
+Welcome to Magento 2.0 documentation! And welcome to Magento 2.0!
+
+Here we explain the Magento platform and components from the perspective of several audiences: merchants, web store developers (frontend developers), [extension](https://glossary.magento.com/extension) developers, system administrators, installers, and integrators.
+
+Magento is a highly-customizable eCommerce platform and content management system that is primarily used to build online storefronts or websites for selling merchandise.
+
+Magento is written using the [PHP](https://glossary.magento.com/php) programming language, and leverages elements of the Zend framework and the model-view-controller architecture. Magento runs on the MySQL relational database, and Magento schema and tables are included in the Magento installation package.
+
+## Help improve this documentation {#help}
+
+Magento 2.0 product documentation is hosted on GitHub, and we welcome your
+feedback there.
+
+Click the **Edit this page on GitHub** link at the top of a documentation page to
+open the file in our GitHub repository, where you are invited to suggest changes
+by creating pull requests, or open a discussion by creating an issue.
+
+For more information, see our [Contributors Guide](https://github.com/magento/devdocs/blob/master/.github/CONTRIBUTING.md).
+
+{:.ref-header}
+Related topics
+
+*  [Release Notes]({{ page.baseurl }}/release-notes/bk-release-notes.html)
+*  [Architecture Guide]({{ page.baseurl }}/architecture/bk-architecture.html)

src/guides/v2.4/bk-get-started-magento.md

@@ -5,4 +5,6 @@ functional_areas:
   - Configuration
   - System
   - Setup
+migrated_to: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cli/configuration-management/set-configuration-values.html
+layout: migrated
 ---

src/guides/v2.4/bk-get-started-magento.md

@@ -5,4 +5,6 @@ functional_areas:
   - Configuration
   - System
   - Setup
+migrated_to: https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cli/static-view/static-view-file-deployment.html
+layout: migrated
 ---

src/guides/v2.4/config-guide/cli/config-cli-subcommands-config-mgmt-parent.md

@@ -0,0 +1,75 @@
+---
+group: inventory
+title: Inventory management architecture
+migrated_to: https://developer.adobe.com/commerce/php/architecture/modules/inventory-management/
+layout: migrated
+---
+
+Magento 2 is a highly modular system that allows 3rd-party developers to extend and customize the system on many levels. As a result, a developer can replace or add any component (module) without affecting the rest of the system.
+
+Module interchangeability was one of the main reasons behind introducing [Service Layer]({{ page.baseurl }}/architecture/archi_perspectives/service_layer.html) in Magento 2. By using service contracts and providing extensions over them, 3rd-party developers can:
+
+*  Enhance out-of-the-box business logic
+*  Replace a module without breaking the system or other extensions relying on these contracts
+
+In Magento 2, a set of interfaces in a module's `/Api` directory typically define the service contracts, including the APIs and their implementations. A module interface expresses the elements (entity interfaces and services to manipulate them) that the module requires. These elements defined in the interface represent a gateway for communication between modules. The implementation contains the working business logic that corresponds to the elements declared in the interface.
+
+By placing service contracts (APIs), implementations, and UI code in the same module, Magento combines different architectural layers of the system in the scope of one component. Unfortunately, this means that a developer who wants to tweak a module's UI would be changing the same module as another developer who would like to substitute the  implementation for predefined business logic. Even modules that the developer expects to be used in headless Magento installations (those that don't use the Admin at all) must contain UI code.
+
+## Inventory management service layer
+
+Implementing a good modular architecture means maintaining a loose coupling between components of the system, reducing dependencies on components that are not needed for a particular deployment. To allow modules to be swapped out, we have designed the Inventory Management modules to follow the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle) (SRP). Each module has responsibility over a single part of the functionality, and all of its services are narrowly aligned with that responsibility.
+
+As a result of applying SRP to module responsibilities (while taking into account the multi-layered architecture of Magento), Inventory Management is comprised of independent modules responsible for:
+
+*  Service contract APIs
+*  Implementation of the business logic for APIs
+*  Admin UI
+*  Frontend UI
+
+The Admin and frontend UIs can be separated, because it's possible to have two different technology stacks. The Admin UI uses UI components, while the frontend UI can use the [PWA](https://developer.adobe.com/commerce/pwa-studio/) studio stack, consisting of technology such as webpack, React, Redux, and GraphQL.
+
+Now, instead of creating one module that covers a specialized business domain, we create up to four modules, each one responsible for a dedicated layer of the system to provide high granularity for customizations. For example, in the standard Magento architecture, the `InventorySales` module would have contained all the APIs, business logic, and UI definitions. Now, these responsibilities are defined in the `InventorySales`,  `InventorySalesApi`, `InventorySalesAdminUI`, and `InventorySalesFrontendUI` modules.
+
+This approach implies additional code limitations in the modules:
+
+*  All modules should depend on the API module. Implementations can be swapped in `di.xml` files.
+*  API modules should contain web API tests. These tests cover API endpoints agnostically to the implementation details. Example: `InventoryApi\Tests\Api\*`
+*  Only UI modules should contain MFTF tests, because these tests cover the interaction between the user and the UI. Example: `InventoryCatalogAdminUi\Test\Mftf\*`.
+
+## Module dependencies
+
+The list of Inventory Management dependencies varies, depending on whether the merchant has installed a headless version of Magento. These merchants have integrated Magento with external Enterprise Resource Planning (ERP) software, and they often consider the ERP software to be the "source of truth" for processes like order processing and inventory tracking. The ERP provides its own UI for managing information and processes. Attempting to use the Magento UI to manage the same things would be excessive and would lead to sophisticated bi-directional synchronization of all changed data.
+
+### Dependencies in a standard installation
+
+For non-headless installations, Inventory Management has dependencies on the following modules:
+
+*  Backend
+*  BundleProduct
+*  Catalog
+*  CatalogInventory (legacy)
+*  ConfigurableProduct
+*  Directory
+*  EAV
+*  GroupedProduct
+*  ImportExport
+*  Reports
+*  Sales
+*  Shipping
+*  Store
+*  UI
+
+### Dependencies in a headless installation
+
+In headless installations, Inventory Management is dependent on the following modules:
+
+*  BundleProduct
+*  Catalog
+*  CatalogInventory (legacy)
+*  ConfigurableProduct
+*  EAV
+*  GroupedProduct
+*  ImportExport
+*  Sales
+*  Store