Merge pull request #416 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/microsoftdocs/architecture-center (branch master)

docs/cloud-adoption/migrate/azure-migration-guide/manage-costs.md

@@ -22,7 +22,7 @@ The tools in this article include:
 > - Azure Migrate
 > - Azure pricing calculator
 > - Azure TCO calculator
-> - Azure Cost Management by Cloudyn
+> - Azure Cost Management
 > - Azure Advisor
 
 The processes described in this article may also require a partnership with IT managers, finance, or line-of-business application owners. For guidance on partnering with these roles, see the Cloud Adoption Framework article on establishing a cost-conscious organization (coming in Q3 2019).

docs/cloud-adoption/migrate/index.md

@@ -15,12 +15,6 @@ layout: LandingPage
 
 Any enterprise-scale [cloud adoption plan](../plan/index.md), will include workloads which do not warrant significant investments in the creation of new business logic. Those workloads could be moved to the cloud through any number of approaches; Lift & Shift, Lift & Optimize, or Modernize. Each of which is considered a migration. The following exercises will help establish the iterative processes to assess, migrate, optimize, secure and manage those workloads.
 
-## Iterative migration process
-
-At its core, migration to the cloud consists of four simple phases: Assess, Migrate, Optimize, and Secure & Manage. This section of CAF teaches readers to maximize the return from each phase of the process and align those phases with your cloud adoption plan. The following graphic illustrates those phases in an iterative approach:
-
-![Cloud Adoption Framework migration model](../_images/operational-transformation-migrate.png)
-
 ## Getting started
 
 To prepare you for this phase of the cloud adoption lifecycle, the framework suggests the following five exercises:
@@ -125,6 +119,12 @@ To prepare you for this phase of the cloud adoption lifecycle, the framework sug
 </ul>
 <!-- markdownlint-enable MD033 -->
 
+## Iterative migration process
+
+At its core, migration to the cloud consists of four simple phases: Assess, Migrate, Optimize, and Secure & Manage. This section of CAF teaches readers to maximize the return from each phase of the process and align those phases with your cloud adoption plan. The following graphic illustrates those phases in an iterative approach:
+
+![Cloud Adoption Framework migration model](../_images/operational-transformation-migrate.png)
+
 ## Creating a balanced cloud portfolio
 
 Any balanced technology portfolio has a mixture of assets in various states. Some applications are scheduled for retirement and given minimal support. Other applications or assets are supported in a maintenance state, but the features of those solutions are stable. For newer business processes, changing market conditions will likely spur ongoing feature enhancements or modernization. When opportunities to drive new revenue streams arise, new applications or assets are introduced into the environment. At each stage of an asset's lifecycle, the impact any investment has on revenue and profit will change. The later the lifecycle stage, the less likely a new feature or modernization effort will yield a strong return on investment.
@@ -135,8 +135,6 @@ The cloud provides various adoption mechanisms, each with similar degrees of inv
 
 An effective journey needs a target destination. Establish a rough vision of the end state before taking the first step. This infographic outlines a starting point consisting of existing applications, data, and infrastructure, which defines the digital estate. During the migration process, each asset is transitioned via one of the options on the right.
 
-![Infographic of the migration options](../_images/migration/migration-options.png)
-
 ## Migration implementation
 
 These articles outlines two journeys, each with a similar goal&mdash;to migrate a large percentage of existing assets to Azure. However, the business outcomes and current state will significantly influence the processes required to get there. Those subtle deviations result in two radically different approaches to reaching a similar end state.

docs/reference-architectures/enterprise-integration/basic-enterprise-integration.md

@@ -51,7 +51,7 @@ Your specific requirements might differ from the generic architecture shown here
 
 Use the API Management Basic, Standard, or Premium tiers. These tiers offer a production service level agreement (SLA) and support scale out within the Azure region. Throughput capacity for API Management is measured in *units*. Each pricing tier has a maximum scale-out. The Premium tier also supports scale out across multiple Azure regions. Choose your tier based on your feature set and the level of required throughput. For more information, see [API Management pricing][apim-pricing] and [Capacity of an Azure API Management instance][apim-capacity].
 
-Each Azure API Management instance has a default domain name, which is a subdomain of `azure-api.net` &mdash, for example, `contoso.azure-api.net`. Consider configuring a [custom domain][apim-domain] for your organization.
+Each Azure API Management instance has a default domain name, which is a subdomain of `azure-api.net`, for example, `contoso.azure-api.net`. Consider configuring a [custom domain][apim-domain] for your organization.
 
 ### Logic Apps