Merge pull request #226236 from Blackmist/migration

prmerger-automator[bot] · web-flow · commit b3c439920d9f · 2023-02-03T18:27:54.000Z
rewording per feedback
diff --git a/articles/machine-learning/concept-azure-machine-learning-v2.md b/articles/machine-learning/concept-azure-machine-learning-v2.md
@@ -278,5 +278,5 @@ An Azure Machine Learning [component](concept-component.md) is a self-contained
 
 ## Next steps
 
-* [How to migrate from v1 to v2](how-to-migrate-from-v1.md)
+* [How to upgrade from v1 to v2](how-to-migrate-from-v1.md)
 * [Train models with the v2 CLI and SDK](how-to-train-model.md)
diff --git a/articles/machine-learning/concept-v2.md b/articles/machine-learning/concept-v2.md
@@ -112,7 +112,7 @@ The Azure Machine Learning Python SDK v1 doesn't have a planned deprecation date
 
 ## Next steps
 
-* [How to migrate from v1 to v2](how-to-migrate-from-v1.md)
+* [How to upgrade from v1 to v2](how-to-migrate-from-v1.md)
 * Get started with CLI v2
 
     * [Install and set up CLI (v2)](how-to-configure-cli.md)
diff --git a/articles/machine-learning/how-to-migrate-from-v1.md b/articles/machine-learning/how-to-migrate-from-v1.md
@@ -1,7 +1,7 @@
 ---
-title: 'Migrate from v1 to v2'
+title: 'Upgrade from v1 to v2'
 titleSuffix: Azure Machine Learning
-description: Migrate from v1 to v2 of Azure Machine Learning REST APIs, CLI extension, and Python SDK.
+description: Upgrade from v1 to v2 of Azure Machine Learning REST APIs, CLI extension, and Python SDK.
 services: machine-learning
 ms.service: machine-learning
 ms.subservice: core
@@ -77,9 +77,9 @@ This section gives an overview of specific resources and assets in Azure ML. See
 
 ### Workspace
 
-Workspaces don't need to be migrated with v2. You can use the same workspace, regardless of whether you're using v1 or v2. 
+Workspaces don't need to be upgraded with v2. You can use the same workspace, regardless of whether you're using v1 or v2. 
 
-If you create workspaces using automation, do consider migrating the code for creating a workspace to v2. Typically Azure resources are managed via Azure Resource Manager (and Bicep) or similar resource provisioning tools. Alternatively, you can use the [CLI (v2) and YAML files](how-to-manage-workspace-cli.md#create-a-workspace).
+If you create workspaces using automation, do consider upgrading the code for creating a workspace to v2. Typically Azure resources are managed via Azure Resource Manager (and Bicep) or similar resource provisioning tools. Alternatively, you can use the [CLI (v2) and YAML files](how-to-manage-workspace-cli.md#create-a-workspace).
 
 For a comparison of SDK v1 and v2 code, see [Workspace management in SDK v1 and SDK v2](migrate-to-v2-resource-workspace.md).
 
@@ -107,9 +107,9 @@ For a comparison of SDK v1 and v2 code, see [Compute management in SDK v1 and SD
 
 ### Endpoint and deployment (endpoint and web service in v1)
 
-With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your existing v1 model deployments and web services will continue to function as they are, but Using SDK/CLI v1 to deploy models on ACI or AKS as web services is now consiered as **legacy**. For new model deployments, we recommend migrating to v2. In v2, we offer [managed endpoints or Kubernetes endpoints](./concept-endpoints.md). The following table guides our recommendation:
+With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your existing v1 model deployments and web services will continue to function as they are, but Using SDK/CLI v1 to deploy models on ACI or AKS as web services is now consiered as **legacy**. For new model deployments, we recommend upgrading to v2. In v2, we offer [managed endpoints or Kubernetes endpoints](./concept-endpoints.md). The following table guides our recommendation:
 
-|Endpoint type in v2|Migrate from|Notes|
+|Endpoint type in v2|Upgrade from|Notes|
 |-|-|-|
 |Local|ACI|Quick test of model deployment locally; not for production.|
 |Managed online endpoint|ACI, AKS|Enterprise-grade managed model deployment infrastructure with near real-time responses and massive scaling for production.|
@@ -118,7 +118,7 @@ With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your exist
 |Azure Arc Kubernetes|N/A|Manage your own Kubernetes cluster(s) in other clouds or on-premises, giving flexibility and granular control at the cost of IT overhead.|
 
 For a comparison of SDK v1 and v2 code, see [Upgrade deployment endpoints to SDK v2](migrate-to-v2-deploy-endpoints.md).
-For upgrade steps from your existing ACI web services to managed online endpoints, see our [upgrade guide article](migrate-to-v2-managed-online-endpoints.md) and [blog](https://aka.ms/acimoemigration).
+For migration steps from your existing ACI web services to managed online endpoints, see our [upgrade guide article](migrate-to-v2-managed-online-endpoints.md) and [blog](https://aka.ms/acimoemigration).
 
 ### Jobs (experiments, runs, pipelines in v1)
 
@@ -171,7 +171,7 @@ For details about Key Vault, see [Use authentication credential secrets in Azure
 
 ## Scenarios across the machine learning lifecycle
 
-There are a few scenarios that are common across the machine learning lifecycle using Azure ML. We'll look at a few and give general recommendations for migrating to v2.
+There are a few scenarios that are common across the machine learning lifecycle using Azure ML. We'll look at a few and give general recommendations for upgrading to v2.
 
 ### Azure setup
 
@@ -203,7 +203,7 @@ The solution accelerator for MLOps with v2 is being developed at https://github.
 
 ### A note on GitOps with v2
 
-A key paradigm with v2 is serializing machine learning entities as YAML files for source control with `git`, enabling better GitOps approaches than were possible with v1. For instance, you could enforce policy by which only a service principal used in CI/CD pipelines can create/update/delete some or all entities, ensuring changes go through a governed process like pull requests with required reviewers. Since the files in source control are YAML, they're easy to diff and track changes over time. You and your team may consider shifting to this paradigm as you migrate to v2.
+A key paradigm with v2 is serializing machine learning entities as YAML files for source control with `git`, enabling better GitOps approaches than were possible with v1. For instance, you could enforce policy by which only a service principal used in CI/CD pipelines can create/update/delete some or all entities, ensuring changes go through a governed process like pull requests with required reviewers. Since the files in source control are YAML, they're easy to diff and track changes over time. You and your team may consider shifting to this paradigm as you upgrade to v2.
 
 You can obtain a YAML representation of any entity with the CLI via `az ml <entity> show --output yaml`. Note that this output will have system-generated properties, which can be ignored or deleted.
 
diff --git a/articles/machine-learning/migrate-to-v2-command-job.md b/articles/machine-learning/migrate-to-v2-command-job.md
@@ -19,7 +19,7 @@ In SDK v2, "experiments" and "runs" are consolidated into jobs.
 
 A job has a type. Most jobs are command jobs that run a `command`, like `python main.py`. What runs in a job is agnostic to any programming language, so you can run `bash` scripts, invoke `python` interpreters, run a bunch of `curl` commands, or anything else.
 
-To upgrade, you'll need to change your code for submitting jobs to SDK v2. What you run _within_ the job doesn't need to be migrated to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more details, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
+To upgrade, you'll need to change your code for submitting jobs to SDK v2. What you run _within_ the job doesn't need to be upgraded to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more details, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
 
 This article gives a comparison of scenario(s) in SDK v1 and SDK v2.
 
diff --git a/articles/machine-learning/migrate-to-v2-execution-automl.md b/articles/machine-learning/migrate-to-v2-execution-automl.md
@@ -1,7 +1,7 @@
 ---
 title: Upgrade AutoML to SDK v2
 titleSuffix: Azure Machine Learning
-description: Migrate AutoML from v1 to v2 of Azure Machine Learning SDK
+description: Upgrade AutoML from v1 to v2 of Azure Machine Learning SDK
 services: machine-learning
 ms.service: machine-learning
 ms.subservice: core
diff --git a/articles/machine-learning/migrate-to-v2-execution-hyperdrive.md b/articles/machine-learning/migrate-to-v2-execution-hyperdrive.md
@@ -21,7 +21,7 @@ A job has a type. Most jobs are command jobs that run a `command`, like `python
 
 A sweep job is another type of job, which defines sweep settings and can be initiated by calling the sweep method of command.
 
-To migrate, you'll need to change your code for defining and submitting your hyperparameter tuning experiment to SDK v2. What you run _within_ the job doesn't need to be migrated to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more information, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
+To upgrade, you'll need to change your code for defining and submitting your hyperparameter tuning experiment to SDK v2. What you run _within_ the job doesn't need to be upgraded to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more information, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
 
 This article gives a comparison of scenario(s) in SDK v1 and SDK v2.
 
diff --git a/articles/machine-learning/migrate-to-v2-execution-parallel-run-step.md b/articles/machine-learning/migrate-to-v2-execution-parallel-run-step.md
@@ -24,9 +24,9 @@ In SDK v2, "Parallel run step" is consolidated into job concept as `parallel job
 To upgrade your current sdk v1 parallel run step to v2, you'll need to 
 
 - Use `parallel_run_function` to create parallel job by replacing `ParallelRunConfig` and `ParallelRunStep` in v1.
-- Migrate your v1 pipeline to v2. Then invoke your v2 parallel job as a step in your v2 pipeline. See [how to migrate pipeline from v1 to v2](migrate-to-v2-execution-pipeline.md) for the details about pipeline migration.
+- Upgrade your v1 pipeline to v2. Then invoke your v2 parallel job as a step in your v2 pipeline. See [how to upgrade pipeline from v1 to v2](migrate-to-v2-execution-pipeline.md) for the details about pipeline upgrade.
 
-> Note: User __entry script__ is compatible between v1 parallel run step and v2 parallel job. So you can keep using the same entry_script.py when you migrate your parallel run job.
+> Note: User __entry script__ is compatible between v1 parallel run step and v2 parallel job. So you can keep using the same entry_script.py when you upgrade your parallel run job.
 
 This article gives a comparison of scenario(s) in SDK v1 and SDK v2. In the following examples, we'll build a parallel job to predict input data in a pipelines job. You'll see how to build a parallel job, and how to use it in a pipeline job for both SDK v1 and SDK v2.
 
diff --git a/articles/machine-learning/migrate-to-v2-execution-pipeline.md b/articles/machine-learning/migrate-to-v2-execution-pipeline.md
@@ -21,7 +21,7 @@ A job has a type. Most jobs are command jobs that run a `command`, like `python
 
 A `pipeline` is another type of job, which defines child jobs that may have input/output relationships, forming a directed acyclic graph (DAG).
 
-To migrate, you'll need to change your code for defining and submitting the pipelines to SDK v2. What you run _within_ the child job doesn't need to be migrated to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more information, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
+To upgrade, you'll need to change your code for defining and submitting the pipelines to SDK v2. What you run _within_ the child job doesn't need to be upgraded to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more information, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
 
 This article gives a comparison of scenario(s) in SDK v1 and SDK v2. In the following examples, we'll build three steps (train, score and evaluate) into a dummy pipeline job. This demonstrates how to build pipeline jobs using SDK v1 and SDK v2, and how to consume data and transfer data between steps.
 
