We all run into problems—physics problems, real-life emergencies, coding frustrations, lab setups, you name it. The instinct is often to jump straight into action, but that’s usually how mistakes get made. APEX is a simple framework I use in physics and in everyday thinking to slow things down, bring structure to the chaos, and make better decisions.
APEX stands for: Assess → Plan → Execute → eXamine
It works because it gives you a sequence. Order matters. You can’t plan before you understand the situation, you shouldn’t execute before you have a plan, and you definitely shouldn’t walk away before checking if things actually worked.
Why APEX?
APEX turns “where do I even start?” into something predictable and manageable. Whether you’re solving a Coulomb’s Law problem or dealing with a real-world emergency, the steps don’t change. Break the problem into parts, think clearly, and avoid panic.
The Four Steps
1. Assess
What do you know? What don’t you know? What’s the situation? This step is about gathering information without judgment or rushing.
2. Plan
What tools, equations, or actions do you need? You form a strategy—simple, clear, and executable.
3. Execute
Do the thing. In a physics problem, this means plugging in values, drawing diagrams, or performing the calculation. In real-life scenarios, this is where you actually act on your plan.
4. eXamine
Did it work? Does the answer make sense? Do you need to adjust anything? Most problems don’t require perfection—they require reflection.
APEX Resource Files
I use APEX constantly in my physics classes. It’s especially helpful for problems that seem overwhelming at first glance. In the APEX document, I walk step-by-step through a Coulomb’s Law example involving two charged nanobots in a fluid channel. Students see how each APEX step narrows the chaos into a clean calculation.
The accompanying slide deck offers a concise visual version of the same idea, showing how Assess–Plan–Execute–eXamine can be taught quickly and reinforced frequently.
Here is how to move a simple WordPress blog to Azure Web App Service. This method is not the simplest but it works well enough and is pretty clean.
Backup
Export the database with a tool such as phpMyAdmin. Then zip up all the files from the wp-content folder.
Or you could use a commercial plugin to to the backup and restore. I don’t like the ones I’ve tried and the manual way is fairly simple.
Create Web App in Azure
In Azure portal, Create a New Resource
Search for “WordPress” then create
Next, fill out the forms with values that make sense, although a few things to pay attention to are:
Database Provider
If your web site gets very little traffic, then choosing “MySQL In App” is reasonable and it’ll save money; About $250/month. The main limitation with this option is the site cannot scale out to handle sudden, heavy loads. However, you can “scale up” the service tier which may help.
App Service Options
App Service Plan
Choose the app service that’s right for you. In this example, we picked the lowest price tier and expect it’ll be upgraded later after some testing.
Keep in mind you can reasonably add up to 5 or so websites within a production tier service plan if they are low traffic and not resource needy.
D1 price tier
Configure WordPress
After the deployment, go to the resource overview page and copy the site’s URL.
Resource Overview Page
Follow URL to the WordPress setup page and do the initial setup.
Fill out the form to initialize WordPress then login to the fresh site. The username and such isn’t needed beyond getting logged in for the first time because in the next steps the whole site is restored from backup.
Initialize the WordPress site
Restore from the backup
How to do this part depends on what method used to backup the website. If you are using a plugin then install it and follow its instructions.
Manual restore
Manual restore is basically two steps:
Import the database using the phpMyAdmin tool
Upload the wp-content folder contents to the website
Import database – Click on “MySQL in App” on the left-side menu then find “Manage” to use the phpMyAdmin tool. Use phpMyAdmin to drop the existing database tables then import your site’s database.
Upload Files – First you need the login credentials. Look in Deployment Center -> “Deployment Credentials” to get what you need to connect to the document root of the web app, using SFTP.
Using your favorite SFTP application, connect to the website and upload your wp-content folder. I recommend zipping up the wp-content folder and upload that. Then connect using the console to unzip the file.
Find the SFTP URL and credentials
Console/Terminal – Click on “Console” in the left-side menu to use command line tools such as Zip, Gzip, Tar, etc.
Finish up
After the import is successful, login with an account from your restored website and do:
Go to Settings -> Permalinks and click the Save button to rebuild them.
Edit the wp-config file “Authentication Unique Keys and Salts” and perhaps other settings to reflect what you had before. Do Not replace the wp-config file outright because it is specifically configured to work with Azure.
Back in the Deployment Center, disconnect from the gitHub repository; You don’t need it anymore.
Extras
For the most part, the site is ready to use and it’s a good idea to review everything is working now.
Fix URLs
Install “Better Search Replace” plugin to change your website URLs if needed. Usually this is because your domain name had to change. For example, “n390.com” moved to “n390.com”.
Add a custom domain name
After the content is imported you can browse the App Service URL and everything should be as it should. However, the hostname is using YOURWEBSITE.azurewebsites.net domain name.
On your Azure Web App blade’s left-side menu go to Custom Domain and click on “Add a custom domain”. Follow the instructions to validate ownership then it should be good-to-go.
Add TLS/SSL
Good news! SSL is available in Azure. But, if you want to add one to your custom domain, then you gotta upgrade to at least the Basic Plan.
Click on TLS/SSL settings in the left-side menu then look in “Private Key Certificates” to create your own. Follow these instructions for complete details.
Before adding a new disk, it’s a good idea to see what is there now. This will make finding the new disk much easier. SSH in to the VM and run the command sudo fdisk -l
Current disks
Create a new data disk
The data disk you create can be independent of the virtual machine. This means it could be created separately and used on any VM. Think of this step like going to the store and buying a new, blank hard disk drive. We’ll attach it to the VM later.
There are several ways to create a disk but in this exercise, let’s use the Azure portal to create a data disk on its own. Click on “Create a resource” in the Azure portal and search for “Managed Disks”.
Create New Managed Disk
Platform managed encryption is the default and works fine for most cases. Encryption “at rest” means the data that is written to the physical disk in Azure’s data centers is encrypted. It is decrypted to put into memory as a virtual disk for your VM but the actual, physical disk is secured.
Using the default encryption-at-rest option
Attach the disk to your VM
Go to the virtual machine you wish to add a data disk for.
You’ll notice in this step you could just as easily create a new disk directly to the VM. However, I created the one separately to highlight the flexibility and independence of data disks. This is an important concept and useful in many situations. For example, you could manage data disks in a different resource group and swap them around as needed.
Click on Disks in the menu
Click on “Add data disk” and select it from the drop-down list
Save
Add data disk to VM
Prepare the disk in Linux
Login the the virtual machine using SSH or the serial console in the VM pane. Preparation of a new disk for use in Linux is basically two parts:
Partition the disk
Write file system to the disk; Format it
First, find the new disk using the commandsudo fdisk -l and compare with the set of disks found earlier. In this case the new disk is /dev/sda
The new disk shows itself
Partition the new disk
Now that we know with a high degree of confidence which is the new disk let’s partition it using fdisk:
sudo fdisk /dev/sda
Use the n command to add a new partition.
Choose p for a primary partition
Accept the default values for the next three options
Enter w to write the partition and finish
Partition the new disk
Format the new disk
Choose the file system format you want such as EXT4, FAT, MSDOS, etc. To see the different file system utilities on your system do: ls /sbin/mkfs*
In this case, we will format the disk with ext4 which is just fine.
Important! Notice the device path is now /dev/sda1. This is the result of partitioning the disk so make sure not to overwrite anything.
A word of caution. Microsoft Azure uses the /mnt directory as it’s temporary storage spot. Do not mount your disks there. To be safe, I like to create a new directory like /datadisks and use that.
Azure Resource Manager templates are JavaScript Object Notation (JSON) files that define the infrastructure and configuration for your resources. In this case a virtual machine.
Steps in brief
Get the virtual machine template files from a known good deployment within Azure portal
Edit the parameters.json file
Run the deployment in PowerShell
Get the template files
There are several ways to get a template file for your deployments. Such as creating it from scratch, GitHub , or the Azure portal. Here, we are using Azure portal to download two files: template.json and parameters.json.
In the Azure portal go to the virtual machine you want to copy. Then click on the “Export Template” menu and then “Download”.
Download JSON template files
Edit the parameters.json file
The template files can be edited to suit your needs, however, the point of this exercise is to reuse an existing deployment. Looking in the parameters.json file, you’ll see most of the parameters & values are self-explanatory and can stay as is. However to avoid name collisions you’ll need to change only a few values.
These three below relate to the Name of the VM and should be unique:
networkInterfaceName
publicIpAddressName
virtualMachineName
You may notice the the value for the Administrator’s password or public key is “Null”. Azure does not export it in the template file so you must add it back in for the new deployment.
adminPublicKey
Edit the parameters file
Deploy using Powershell
Now we are ready to deploy a new virtual machine based on the template files.
Using variables in the command line is optional although quite useful for scripting later on.
If you don’t give the “DeploymentName” it’ll default to something like “template”. I recommend using a name that’ll make sense when you see it in the Azure portal.
After a few minutes you’ll see some details about the deployment like:
DeploymentName : MyTemplateDeployTests
ResourceGroupName : DemoRG
ProvisioningState : Succeeded
.. and so on
Verify the deployment
If you want, here are steps to get the IP address and then SSH into the VM to look around. FYI, this is a Linux VM.
Get the VM public IP address then login using SSH. This will only work if the template is configured with Network Security Group that allows port 22 OR there is a Network Security Group applied to the selected “subnetName” OR similar.
Get the IP address
In the output of this command will be the VM’s public IP address. Note, $resourceGroupName is reused from previous steps. Replace “virtualMachineName” with the VM name you used in the parameters file.
Get-AzPublicIpAddress -ResourceGroupName $resourceGroupName -Name <VM Name> | select IpAddress
OR This
Get-AzPublicIpAddress -ResourceGroupName $resourceGroupName | Where-Object {$_.name -like "*<VM Name>*" }
OR This
Get-AzPublicIpAddress -ResourceGroupName $resourceGroupName | Where-Object {$_.name -like "*<VM Name>*" } | Select-Object { $_.IpAddress }
Login to the VM
Goto to another terminal window and SSH into the VM. In this case, I am using my private key. Remember the public key was added to the parameters.json file.
