anchor.diff:  To approximate the time it takes to configure a build without executing tasks, you can run `gradle help`. Please use the Gradle Profiler to measure your build as described <<#sec:new_task_gradle_profiler_scenario,further on>>.
   
   [[sec:task_configuration_avoidance_migration_guidelines]]
  -=== Migration Guide
  +== Migration Guide
   
   The following sections will go through some <<#sec:task_configuration_avoidance_general, general guidelines>> to adhere when migrating the build logic as well as <<#sec:task_configuration_avoidance_migration_steps, the steps>> we recommend following.
   We also cover some <<#sec:task_configuration_avoidance_troubleshooting, troubleshooting>> and <<#sec:task_configuration_avoidance_pitfalls, pitfalls>> to help you work around some issues you may encountered during the migration.
   
   [[sec:task_configuration_avoidance_general]]
  -==== General
  +=== General
   1. [[task_configuration_avoidance_guideline_use_help_task]] **Use `help` task as a benchmark during the migration.**
   The `help` task is the perfect candidate to benchmark your migration process.
   In a completely lazy build, https://scans.gradle.com/s/o7qmlmmrsfxz4/performance/configuration?openScriptsAndPlugins=WzFd[a build scan should show no task created immediately or created during configuration].
  
positive.code: * [[task_configuration_avoidance_pitfall_build_scan_plugin]] **The build scan plugin `buildScanPublishPrevious` task is eager until version 1.15.** Upgrade the build scan plugin in your build to use the latest version.
  
  [[sec:task_configuration_avoidance_backward_compatibility_migration]]
  ==== How to keep backward compatibility for plugin authors?
  
  Plugin authors may have additional obligation regarding backward compatibility.
  This section explains two ways for plugin authors to keep their plugins backward compatible with older version of Gradle.
  
  [NOTE]
  ====
  Although allowing your plugin to be backward compatible is good for the users, it is still recommended to move compatibility forward to Gradle 4.9+ sooner rather than later.
  ====
  
  The first method is to compile your plugin against the Gradle 4.9 API and https://github.com/melix/jmh-gradle-plugin/blob/a034aa88805b7a06fa9c5a825d573554b2aa23e2/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy#L289-L296[conditionally call the right APIs], i.e. `TaskContainer#create` vs. `TaskContainer#register` where required.
  This method is highly preferred to the alternative.
  
  The second method is to use Java reflection to cop with the fact that the APIs are unavailable during compilation.
  This method as several performance pitfalls that may be undesired for your users.
  
  It is highly recommended to have sufficient cross-version test coverage using <<test_kit, TestKit>>.
  
  [[sec:old_vs_new_configuration_api_overview]]
  == Old vs New API overview
  
negative.code: may be expected to always execute.
  
  [[sec:task_configuration_avoidance_migration_steps]]
  === Migration Steps
  The first part of the migration process is to go through the code and manually migrate eager task creation and configuration to use lazy APIs.
  The following explores the recommended steps for a successful migration.
  While going through those steps, keep in mind <<#sec:task_configuration_avoidance_general, the guidelines>>.
  
  [NOTE]
  ====
  Using the new API in a plugin will require users to use Gradle 4.9 or newer. Plugin authors should refer to <<sec:task_configuration_avoidance_backward_compatibility_migration>> section.
  ====
  
  1. **Migrate task configuration that affects all tasks (`tasks.all {}`) or subsets by type (`tasks.withType(...) {}`).**
  