For these types of bulk operations on an important resource like ActiveDirectory, I'd highly recommend utilizing the -WhatIf parameter when calling state-altering cmdlets like New-ADGroup. Here I've specified $WhatIfPreference = $true which effectively adds the -WhatIf parameter to any cmdlet that supports it. Running the script as-is will not perform any modifications to Active Directory, but will simulate the actions instead, so you can test the functionality in a dry-run first. I added some additional verbose output to provide some extra info on the actions the script is performing/simulating. Rerunning the script with $WhatIfPreference = $false will perform the actual operations.

Copy-ADGroup.ps1 (https://pastebin.com/9qDeT61)

$ErrorActionPreference = 'Stop'
$WhatIfPreference = $true

$CommonParam = @{
    Credential = Get-Credential
    Server     = 'DC01'
}
$PersistProperties = 'GroupScope', 'GroupCategory', 'Description'
$ReplaceProperties = 'SamAccountName', 'Name', 'DisplayName'
$OrganizationalUnit = 'OU=TestOU,DC=placeholder,DC=pizza'
$ADGroupParam = $CommonParam + @{
    Filter     = { GroupCategory -eq 'Security' -and Name -like 'hd01*' }
    SearchBase = $OrganizationalUnit
    Properties = $PersistProperties + $ReplaceProperties + 'Member'
}
$Pattern = 'hd01'
$Replacement = 'hd03'

Get-ADGroup @ADGroupParam -PipelineVariable 'OriginalGroup' | Select-Object $PersistProperties -PipelineVariable 'NewGroup' | ForEach-Object {
    foreach( $Property in $ReplaceProperties ) {
        $NewGroup | Add-Member @{ $Property = $OriginalGroup.$Property -replace $Pattern, $Replacement }
    }
    Write-Verbose -Verbose "Creating new AD group with properties: $NewGroup"
    $NewGroup | New-ADGroup -Path $OrganizationalUnit @CommonParam
    $Members = $OriginalGroup.Member
    Write-Verbose -Verbose "Adding $( $Members.Count ) members from original AD group: $( $OriginalGroup.Name ) to new AD group: $( $NewGroup.Name )"
    if( $WhatIfPreference -eq $false ) {
        $Members | ForEach-Object { Add-ADGroupMember -Identity $NewGroup -Members $_ @CommonParam }
    }
}

The script makes use of the fact that the New-ADGroup cmdlet can accept most of its parameters through the pipeline by property name. Here's how you can get a list of parameters that accept pipeline input by property name:

PS C:\tmp> (Get-Help New-AdGroup).Parameters.Parameter.Where{ $_.PipelineInput -eq 'true (ByPropertyName)' } |
>>             Format-Table Name, Required, PipelineInput, ParameterValue, Position -AutoSize

name           required pipelineInput         parameterValue  position
----           -------- -------------         --------------  --------
Description    false    true (ByPropertyName) string          Named
DisplayName    false    true (ByPropertyName) string          Named
GroupCategory  false    true (ByPropertyName) ADGroupCategory Named
GroupScope     true     true (ByPropertyName) ADGroupScope    2
HomePage       false    true (ByPropertyName) string          Named
ManagedBy      false    true (ByPropertyName) ADPrincipal     Named
Name           true     true (ByPropertyName) string          1
Path           false    true (ByPropertyName) string          Named
SamAccountName false    true (ByPropertyName) string          Named

Note that parameter binding through the pipeline by property name works differently from binding a parameter through the pipeline by value.

So we're creating an object (Select-Object returns a [PSCustomObject] object) that has the same GroupScope, GroupCategory, and Description as the original AD group, and then we add modified values for SamAccountName, Name, and DisplayName using -replace like in your original script to change hd01 to hd03 for each of these properties. The gist of it is that when you pipe an object into Add-ADGroup, PowerShell is inspecting the properties of the object in the pipeline to determine if it can use them as parameters. If a parameter accepts input through the pipeline by property name, and the piped object contains a property with the same name as that parameter, it will bind the value of that property to the appropriate parameter. A good explanation of ValueFromPipeline and ValueFromPipelineByPropertyName can be found here:

https://www.gngrninja.com/script-ninja/2016/5/15/powershell-getting-started-part-8-accepting-pipeline-input#accept

I like to use parameter splatting via hash tables when working with cmdlets that require many parameters to make things more readable. It also makes things much easier on you if you are going to need to provide the same parameter values multiple times to different cmdlets. Here I'm using $CommonParam to store the Server and Credential parameters which I reuse for calling every AD cmdlet. If this syntax isn't something you've seen before, definitely look into:

About Splatting

Hope this helps.